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(57) Abstract 

An electronic transaction system, which facili- 
tates secure electronic transactions among multiple par- 
ties including cardholders (20), merchants (70), and ser- 
vice providers (SP) (60). The system involves elec- 
tronic cards, commonly known as smart cards, and their 
equivalent computer software package. The card mim- 
ics a real wallet and contains commonly seen finan- 
cial or non-financial instruments such as a credit card, 
checkbook, or driver's license. A transaction is pro- 
tected by a hybrid key cryptographic system and is nor- 
mally carried out on a public network such as the In- 
ternet. Digital signatures and random numbers are used 
to ensure integrity and authenticity. The card utilizes 
secret keys such as session keys assigned by service 
providers (SPs) to ensure privacy for each transaction. 
The SP is solely responsible for validating each partici- 
pant's sensitive information and assigning session keys. 
The only trust relationship needed in a transaction is the 
one that exists between individual participants and the 
SP. 
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1 A CRYPTOGRAPHIC SYSTEM AND METHOD 

FOR ELECTRONIC TRANSACTIONS 

FIELD OF THE INVENTION 
5 The present invention relates generally to a cryptographic system and method for secure 

electronic transactions, and more particularly to an electronic card, which takes the form of a 
"smart card" and/or its equivalent software. 

BACKGROUND OF THE INVENTION 

10 The generic term, "smart card," generally denotes an integrated circuit (IC) card, that is, 

a credit-card-size piece of plastic with an embedded microchip. The IC chip on a smart card 
generally, but not necessarily, consists of a microprocessor (the CPU), read-only memory 
(ROM), random access memory (RAM), an input/output unit, and some persistent memory such 
as electrically erasable programmable read-only memory (EEPROM). The chip can perform 

1 5 arithmetic computations, logic processing, data management, and data communication. 

Smart cards are mainly of two types: contact and contact-less. The International Standard 
Organization (ISO) has established specifications for such electronic cards under the ISO series. 
In particular, ISO 7816 applies to integrated circuit(s) cards. Because of its computing 
capability, a smart card can support a multitude of security features such as authentication, 

20 secured read/write, symmetric key and asymmetric key encryption/decryption. These smart card 
security features make it well suited for electronic commerce where data security and 
authenticity are of primary importance. 

Smart card use has found application in many specialized fields such as mass 
transportation, health insurance, parking, campus, gas, etc. And its potential use in electronic 

25 commerce and other financial areas are gaining popularity at a rapid pace. U.S. Pat. No. 
5,521,362, issued to Robert S. Power on May 28,1996, entitled "Electronic purse card having 
multiple storage memories to prevent fraudulent usage and method therefor," describes an 
electronic purse application. Power's invention demonstrates a smart card's capability to be used 
as a secure financial instrument and not just as a storage device. 

30 As advances in technology push smart-card chip computing to higher speeds and larger 

memory capacity, the concept of a "multi-application" smart card is increasingly becoming 
economically and physically feasible. U.S. Pat. No. 5,530,232 issued to Douglas C. Taylor on 
June 25, 1996, entitled "Multi-application data card," describes a multi-application card, which 
is capable of substituting for a plurality of existing single-application cards and satisfying both 

35 financial and non-financial requirements. The multi-application card uses a conventional data 
link to connect between the smart card and the remote service provider. Taylor's invention, the 
multi-application card, does not relate to any kind of open network or cryptographic method. 

U.S. Pat. No. 5,544,246 issued to Mandelhaum et ah on" on Aug. 5, 1996, entitled "Smart 
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1 card adapted for a plurality of service providers and for remote installation of same," describes 

a smart card, which allows different service providers to coexist on the same smart card. Each 
service provider is considered a user of the smart card and is installed on the card by the 
issuer/owner of the smart card. Each user is allowed to build a tree-like file structure and protect 
5 it with a password file. Mandelbaunfs invention depicts a smart card allows for the creation and 

deletion of multiple applications. Mandelbaunrs smart card controls the access to each 
application by using an appropriate password file. 

U.S. Pat. No. 5,671,279 issued to Taher Elgamal on September 23, 1997, entitled 
"Electronic commerce using a secure courier system," describes a system for implementing 
10 electronic commerce over a public network using public/private key cryptography. The Elgamal 
patent did not mention the use of a smart card as a tool in conducting the electronic commerce 
and the participants were authenticated through the use of digital certificates. The secure courier 
system requires a secured channel such as a Secure Socket Layer (SSL) between the trading 
parties over an open network such as the Internet. 
15 1 . U.S. Pat. No. 5,790,677, issued to Fox et al. on August 4, 1998, entitled "System 

and method for secure electronic commerce transactions," describes a system and method 
having a registration process followed by a transaction process. During the registration 
phase, each participant of a transaction registers with a trusted credential-binding server 
by sending to the server a registration packet. The server produces unique credentials 
20 based upon the request received and sends them to the request originator. During the 

transaction phase, the originator of the transaction requests, receives and verifies the 
credentials of all intended recipients of the commerce document and/or instrument and 
encrypts the document and/or instrument using the public key of the individual recipient. 
Thus, each receiving party can decrypt and access the information intended only for him. 
25 Fox's patent describes a process which reflects the theme of the so called "Secure 

Electronic Transaction" (SET) standard which is an ongoing effort supported by several 
major financial and software companies to establish a digital certificate and certificate 
authority based electronic commerce system. 

U.S. Pat. No. 5,796,840 issued to Derek L. Davis on August 18,1 998, entitled "Apparatus 
30 and method for providing secured communication,"describes a semiconductor device, which is 
capable of generating device-specific key pairs to be used in subsequent message authentication 
and data communication. The semiconductor device uses public/private key cryptography to 
ensure the authenticity of two communicating parties. 

U.S. Pat. No. 5,534,857 issued to Simon G. Laing and Matthew P. Bowcock on July 9, 
35 1996, entitled "Method and System for Secure, Decentralized Personalization of Smart Cards," 
describes a method and apparatus for securely writing confidential data from an issuer to a 
customer smart card at a remote location. A mutual session key for enciphering data transfer 
between a secure terminal and a secure computer is generated by using a common key stored in 
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1 the secure computer and a retailer smart card. 

It is clear from the inventions mentioned above that the architecture of a secure electronic 
commerce system involves a public key infrastructure and digital certificate authority associated 
with it. 

5 On an open network, a secret key-based system is less flexible in terms of key distribution 

and key management, and is more subject to malicious attack. On the other hand, a 
public/private key-based system, with all its advantages over the secret key system, has its own 
daunting task of authenticating transaction parties to one another. The current invention presents 
another system and method, which replaces the need for certificate authorities and digital 

10 certificates. The current invention is a hybrid system for electronic transactions. The hybrid 
system uses public/private keys during the key exchange phase and uses a session key as a secret 
key during the transaction phase. 

SUMMARY OF THE INVENTION 
1 5 The invention is a cryptographic system and method for electronic transactions by using 

an electronic card (EC) in the form of a smart card or equivalent software and communicating 

over a communications network. 

The preferred embodiment of the invention uses an open network, such as the Internet. 

Alternative embodiments of the invention may use other types of networks. An embodiment of 
20 the invention may either use a physical smart card, or alternatively, a smart card, which is 

implemented as computer software package and runs on a computing device such as a personal 

computer (PC). Likewise, a merchant involved in a transaction may use a merchant device, 

which is a point-of-sale terminal, or a device, which uses software on a host computer to 

communicate with an EC and a service provider. When a smart card is used, a smart card reader 
25 is also needed to allow the card to communicate with a host device, such as a network ready 

merchant terminal, a PC, or any other electronic device, which is capable of supporting smart 

card transactions. 

In a public key and digital certificate based system, transaction participants exchange 
public information through the use of digital certificates or other electronic credentials which are 

30 issued and certified by a certificate authority (CA) or credential binding server. The 
communication between the CA or the server and each participant of the transaction must be 
secure. Random numbers and digital signatures are used to ensure the authenticity and validity 
of the messages transmitted among the participants. 

The cryptographic system and method of the preferred embodiment of the invention also 

35 uses public/private key cryptography, but it works in a slightly different way. The cryptographic 
system and method does not seek to create another kind of trust relationship as the one that exists 
between holders of digital certificates and the certificate authorities. It particularly targets large 
membership-based financial institutions such as a large credit card company and all its 
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1 cardholders, or a major bank and all its ATM cardholders as its potential users. Non-financial 

institution can also use this cryptographic system and method to conduct commercial or non- 
financial transactions over a network. 

A service provider (SP) provides some service to its members. Financial institutions are 

5 just one kind of service provider. A service provider can also be non-financial in nature. 

Regardless whether a service provider is a financial institution or a non-financial institution, 
essentially the same process occurs. The only difference between a transaction involving a 
financial institution and a transaction involving a non-financial institution is that the messages 
may include different data fields. 

1 0 When an EC holder signs up with one of the service providers, the service provider creates 

a dedicated entry on the EC. Each entry contains the account information for the service 
provider, the SP's public key, access control information, and other related data. Each EC can 
support a predetermined number (e.g. ten) of such entries and each such entry is a representation 
of one service provider. 

15 By using the public/private key cryptography, the key distribution process is much 

simplified. The EC holder him/her/self or any trusted third party such as a bank branch or even 
a post office can perform the task. The SP's public key is only used for the initial key exchange 
between the SP and the cardholder. After the initial key exchange step, the SP assigns a session 
key, which protects any further message exchange between the cardholder and the SP or between 

20 the cardholders' themselves. 

This hybrid system, which uses both public key/private key cryptography and secret key 
cryptography (i.e., session key), is in contrast to other secret-key systems in that in the hybrid 
system, the secret key (i.e., session key) is valid for a single session and is not applicable to other 
sessions. A session has a determinate length of time. A session may terminate based upon a 

25 time period or upon conditions being satisfied. 

Where a merchant is involved in a transaction, the merchant goes through essentially the 
same procedures as the EC holder to communicate with the SP. The merchant will first perform 
a key exchange with the SP and receive a session key. The session key will be used by the 
merchant for subsequent communication with the SP. The cardholder and the merchant digitally 

30 sign each message going to the SP and the SP similarly signs the response message going back 
to the cardholder and the merchant. 

In the event that a transaction requires interactions with another certificate-based system, 
the SP, after authenticating the cardholder and the merchant based on further information 
exchange after the initial key exchange, can act as a surrogate-certificate for the cardholder and 

35 the merchant. In the most extreme case, the SP performs solely this surrogate function and 
becomes a gateway for the certificate-based system. This type of hierarchy is highly desirable 
since it reduces the number of trust relationships needed to carry out a transaction among 
multiple systems. In addition, it eliminates the users' need to carry certificates. 
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1 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the relationship among the components of a 
system according to an embodiment of the invention. 
5 Figure 2 shows the flow of the two transaction phases via a network. 

Figure 3 is the diagrammatic representation of an EC. 

Figure 4 shows the format of the service provider data area. Each service provider's 
information is allocated an entry in the table and is protected by access conditions. 

Figure 5 shows how the digital signatures are used in an embodiment of the invention. 
10 Figures 6 A through 6Q shows the schematic flow chart of the cryptographic system and 

method used in an embodiment of the invention in order to conduct electronic transactions via 
an open telecommunication network, such as the Internet. 

Figure 7 through Figure 1 1 depicts the final format and content of the combined request 
and response messages in the key exchange phase and the transaction phase. 
1 5 Figure 1 2 shows a service provider conducting a transaction with participants that have 

been arranged in series. 

Figure 13 shows a service provider transaction on a network with participants that have 
been arranged in a hierarchical organization scheme. 

20 

DETAILED DESCRIPTION 

The preferred embodiment of the invention is a cryptographic system and method for 
electronic transactions by using an electronic card (EC) in the form of a smart card or 
equivalent software and communicating over a communications network. 

25 In the preferred embodiment of the invention, the network is an open network such as 

the Internet. In alternative embodiments of the invention, other open networks and/or closed 
networks may be used to establish communication between a service provider and its 
members. For example, a service provider may use its own proprietary financial network to 
communicate with its members. 

30 Any Internet protocol may be used for Internet connections. Example protocols, 

which can be used include TCP/IP, UDP, HTTP, and the like. 

Communication may also be via a communications network transport service such as 
the Public Switched Telephone Network (PSTN) usingtraditional analog telephone service 
(a.k.a. Plain Old Telephone Service or POTS), or by using a digital communication service 

35 such as a T-l, El or DS-3 data circuit, Integrated Services Digital Network (ISDN), Digital 
SubscriberLine (DSL) services, or even using a wireless service, and the like. When 
implemented using such a service the invention may be implemented independent of a 
communications protocol (i.e. at an electrical interface layer). 
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1 Communication may also be via a local area network (LAN) or WideArea Network 

(WAN) such as Ethernet, Token Ring, FDDI, ATM or the like. Example protocols, which 
can be used include TCP/IP, IPX, OSI, and the like. 

Other communication links might include an optical connection, a wireless RF modem 

5 connection, a cellular modem connection, a satellite connection, etc. 

The invention may be employed as long as a communication path can be established 
between a service provider and its members. The examples above are intended to illustrate 
several examples of the various communications environments in which the invention may be 
practiced. As is clear to one ordinarily skilled in the art, the invention is not limited to those 

1 0 environments detailed above. 

The EC can take the form of a smart card device or a software package running on a 
computer system such as a personal computer (PC). When the EC is implemented on a smart 
card, it can be used on a network-ready computer system such as a PC to transact with another 
member and/or a selected service provider. It will need a read/write interface device to 

1 5 communicate with a computer system and some application software such as an Internet browser 
to interface with the cardholder and the network. If the EC is a software package loaded into a 
computer system, then no read/write interface is needed. The exemplary embodiment of the 
invention is for the EC to act as an electronic wallet (or cyber wallet) which functions similar 
to real wallet. A real wallet can carry credit cards, debit cards, ATM cards, health provider 

20 cards, membership cards, cash, etc. An EC has the digital equivalent of all the above-mentioned 
financial and non-financial instruments and enables conducting secure transactions over the 
Internet. 

A service provider member can be a merchant and/or an EC cardholder. A merchant is 
a member who is paid by the service provider as a result of a transaction. A member can be both 

25 a merchant and an EC cardholder. A merchant may engage in a transaction with other 
cardholders, which results in the merchant being paid by the service provider. A merchant may 
also be an EC cardholder and purchase supplies, for example, from a merchant supplier. 

The cryptographic system may involve communication between a service provider and 
any number of service provider members. Thus, communication can be between an EC and an 

30 SP, between a merchant and an SP, between a first EC, a second EC, and an SP, between a first 
merchant, a second merchant, and an SP, etc. An EC may communicate directly with a service 
provider to inquire about an account balance for example. A merchant may communicate with 
a service provider only on his own behalf and not on behalf of an EC because, for example, the 
merchant wants to know his own account balance with the service provider. Communication 

35 between the SP and its members may follow any permutation of the SP and its members. The 
organization of the communication links between the SP and its members may be sequential 
and/or hierarchical. Communication between the SP and its members may also be via routers, 
which route the messages between the SP and its members. 
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1 The cryptographic method is a two-phased key-exchange-transaction model. The first 

phase is a key exchange phase. The second phase is the transaction phase. In the key exchange 
phase, the members exchange keys with the service provider. The members send their keys to 
the service provider and the service provider uses the keys to send a session key to the members. 

5 The session key protects any further message exchange between the cardholder and the SP or 

between the cardholders' themselves. In the transaction phase, either the SP can direct the 
transaction or the cardholders themselves may conduct the transaction. 

Figure 1 is a block diagram showing the relationship among the components of a system 
according to an exemplary embodiment of the invention involving a cardholder, a merchant, and 

1 0 service provider. 

An EC cardholder 20 can conduct a transaction over a network 50 and communicate with 
a merchant either by using an EC read/write device 82 attached to an originating computer 84 
or by using EC equivalent software 92 running on an originating computer unit 90. 

A merchant can conduct a transaction over a network by either using a network-ready 

15 point-of-sale(s) (POS) terminal 40 or by using EC equivalent software running on a merchant 
device 70 to conduct an electronic transaction with a selected service provider 60 via a network 
50 such as the Internet. 

Once the access conditions to the card have been satisfied, the cardholder can perform 
financial or non-financial transactions with other participants of the system through the network 

20 50. In Figure 1 , there are three different scenarios in which a transaction over a network can be 
conducted. 

(1) In a POS transaction (Upper left side of figure 1), the cardholder 20 swipes/inserts an 
EC through/into a merchant's EC reader/writer 30 at a merchant's premises. The EC 
reader/writer is connected to a network-ready merchant POS terminal 40. The network- 

25 ready merchant POS terminal 40 is a secure tamper-resistant programmable device 

comprising an input means such as a keyboard, a display device, a processing unit, and 
an EC read/write device 30 (an EC interface device). It is typically a small computer 
unit such as a PC equipped with a communication link to an open network. The POS 
terminal communicates to the SP via the network 50. 

30 (2) (Right side of figure 1) A cardholder can conduct a transaction with other participants 

of the system by inserting the EC 20 into a read/write device 82, which is connected to 
the cardholder's personal computer 84 which is the originating computer. The 
originating computer connects to a network 50 allowing the EC to communicate with 
the merchant computer unit 70. The merchant computer unit 70 has EC equivalent 

35 software 72 that enables the merchant to receive the EC generated message and 

generates a message combining EC information and merchant information. Then, the 
combined message is sent to the SP over a network. 
(3) (Bottom side of figure 1) A cardholder can conduct a transaction with other participants 
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1 of the system by using EC equivalent software 92 on the customer cardholder's personal 

computer 90. The transaction begins at the originating computer unit 90, that is, the 
cardholder's personal computer. The cardholder conducts the transaction over a 
network 50 and communicates with the merchant's computer unit 70, which in turn 
5 communicates with the SP 60 over a network 50. 

While in the preferred embodiment of the invention, a personal computer is used to hold the 
EC equivalent software, in alternative embodiments of the invention other electronic devices can 
be used to hold the EC equivalent software. 

In the preferred embodiment of the invention, the network used to enable the EC to 
10 communicate with the merchant is the same network used to enable the merchant to 
communicate with the SP. In another embodiment, the network used to enable the EC to 
communicate with the merchant may not be the same network used to enable the merchant to 
communicate with the SP. In yet another embodiment, the network used to enable one merchant 
to communicate with the SP may not be the same as the network used to enable another merchant 
1 5 to communicate with the SP. In still yet another embodiment, the network used to enable an EC 
to communicate to the merchant may not be the same as the network used to enable another EC 
to communicate with another merchant. An embodiment may consist of a multiplicity of 
networks whereby different parties communicate. 

In the preferred embodiment of the invention, a transaction is broken down into two phases: 
20 a key exchange phase and a transaction phase. Figure 2 is a specific case, which illustrates the 
two-phase key-exchange-transaction model where the SP directs the transaction phase. There is 
no direct exchange of sensitive information between participants when the SP directs the 
transaction. 

The key exchange phase is the same where the transaction phase is among the cardholders 
25 themselves and where the SP directs the transaction phase. Where the transaction phase is 
among the cardholders themselves, the cardholders use the SP session key to communicate with 
each other and conduct a transaction. 

Figure 2 demonstrates a financial transaction where the SP directs the transaction phase. 
The transaction shown involves three parties: an EC (a transaction originator) 102, a merchant 
30 104, and a service provider (SP) 106. The originating party is an EC cardholder who is the 
consumer and is represented by the computer unit 102. The computer unit 104 represents the 
merchant. The computer unit 106 represents the service provider. An SP is selected by both an 
EC and merchant. 

Figure 2 demonstrates a financial transaction wherein the process flow is from an EC to a 
35 merchant to an SP. The cryptographic method's process flow is not limited to any particular 
order between merchants and EC cardholders. Figure 2 is merely an example of a particular 
transaction, which flows from EC to merchant to service provider. The process flow can also 
go from merchant to EC to service provider. Figure 2 demonstrates how service provider 
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1 members (in this case, the EC cardholder and the merchant) create, append, and send messages 

to a service provider. 

The ten arrows numbered 1 to 10 in figure 2 show how the messages flow among the three 
parties during the two transactions phases. Steps 1 through 4 belong to the key exchange phase 

5 and steps 5 through 10 belong to the transaction phase. In figure 2, the merchant serves as an 

intermediary between the EC and SP. In step 1 , the key exchange request is formatted by the EC 
and sent to merchant. In step 2, the merchant combines his own key exchange message with the 
EC's key exchange message and sends the combination key exchange message to an SP. In 
step 3, the SP formats a key exchange response for the merchant, formats a key exchange 

1 0 response for the EC, combines the key exchange responses to form a combined key exchange 
response and sends the combined key exchange response to the merchant. In step 4, the 
merchant separates the key exchange response for the merchant from the key exchange response 
for the EC and forwards the EC's key exchange response message back to the EC. Step 4 
concludes the main activities in the key exchange phase. 

1 5 The transaction phase begins with step 5. In step 5, the EC formats its transaction request 

message and sends it to merchant. In step 6, the merchant combines the received transaction 
request message with his own transaction request message and sends the combination transaction 
request message to the SP. In step 7, the SP formats a transaction response message for the 
merchant formats a transaction response message for the EC, combines the transaction response 

20 messages and sends the combined transaction response message back to merchant. In step 8, the 
merchant separates the transaction response message for the merchant from the transaction 
response message for the EC and forwards the EC's transaction response message back to the 
EC. In step 9, the EC formats a confirmation message and sends it to the merchant. In step 10, 
the merchant combines the received confirmation message with his own confirmation message 

25 and sends the combination confirmation message the SP. Step 10 concludes the transaction 
phase of a transaction. 

While figure 2 demonstrates a simple transaction, some transactions may involve multiple 
messages. During some transactions, more than one message may be required to complete each 
phase, in which case, those messages will follow the same rules of combination and flow pattern. 

30 For example, during the transaction phase, the SP may require that the EC and the merchant send 
over account information first. If the account information is verified to be valid, the SP sends 
confirmation of the account information in the response message. Once the merchant and the 
EC receives the response message, then the EC and the merchant send the transaction amount 
and other transaction related information in the next message going to the SP. The SP 

35 subsequently approves or disapproves the transaction. The steps in figure 2 apply to both the 
account message and the transaction message. 

If the completion of a transaction requires interaction with some external system such as 
a public key and digital certificate based system 108, the SP will act as a surrogate-certificate 
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1 for the EC and the merchant and deal with the external system on behalf of the EC and the 

merchant A desired result of the invention is to shield all of the participants of a transaction 
from an external system and therefore reduce the number of trust relationships needed to 
complete a transaction. If a participant of a transaction has dual membership of this system and 

5 an external system, then he has a choice of either acting as a member of this system or as a 

member of an external system. In the latter case, the SP will interface with the participants using 
the rules of an external system. For example, to deal with an external public and digital 
certificate or credential based system, the SP has in its possession all of the required certificate(s) 
or credential(s) which satisfies the trust relationship demanded by the external system. Such 

10 credentials are required in order for the SP and the external system to complete the transaction 
initiated by the EC and the merchant. In this case, only the SP needs to have a trust relationship 
with the external system. Based on this trust relationship, individual ECs and merchants are able 
to complete transactions with the hypothetical external system. 

Figure 3 is a diagrammatic representation of a preferred embodiment of an EC. In a 

1 5 preferred embodiment of the invention, an EC is internally composed of the software/hardware 
components shown in Figure 3. The EC is ISO 7816-based and supports the same kind of 
communication protocols and commands as defined in ISO 7816. 

The EC has a card operating system 550 to manage the EC's internal resources. The on- 
card cryptographic service 650 can be implemented in software or be provided by a 

20 cryptographic co-processor (not shown in figure 3), or other hardware solutions, or a hybrid of 
software and hardware. 

One of the unique features of the EC is the service provider data area (SPDA) in the EC 
memory, which contains the service providers' account and key information. The service 
provider data area (SPDA) 700 contains a number of slots. In the preferred embodiment, the 

25 SPDA contains a pre-defined number (e.g. ten) of slots one for each potential service provider. 
In another embodiment, the number of slots may be dynamically changed. A record for each 
service provider can be placed into an empty slot. Each record contains the account number, 
public key, and other related information for a specific service provider. 

Depending on the EC design, the SPDA can optionally allow each SP to include some 

30 software (such as an "applet" in the JAVA terminology) to manage its own on-card data and 
provide an interface between the SP card data and the host application. In other words, the SPDA 
can contain more than just simple data; it can allow each SP to put a self-contained application 
program (such as an applet) on the EC to provide its own unique service to the cardholder. The 
advantage of this type of design is that the EC itself is now detached from the type of service it 

35 can provide. Each SP can bring with it its own service capability. When another SP replaces 
an on-card SP, there will be no change necessary to the EC platform. The new SP applet is 
simply loaded into the card and it will perform what it is designed to do. 

In the SPDA, each service provider is allocated space for public keys. In many transactions, 
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1 only one key pair is used, but for some online transactions, two or more key pairs are required. 

If the SP uses the same public/private key pair for both the incoming and the signing of outgoing 
messages, then one public key is enough. If the SP uses a different key pair for signing, then 
both SP public keys (one for incoming messages and one for the signing of outgoing messages) 
5 are required in the SPDA. 

In the preferred embodiment of the invention, two public/private key pairs rather than one 
public/private key pair is used to communicate with other applications through a network 
because using two public/private key pairs rather than one public/private key pair provides 
greater security. One pair is used for decrypting an incoming message, i.e., the sender encrypts 
10 the message using the recipient's public key and the recipient decrypts the message using the 
corresponding private key. The other pair is for the sender to digitally sign the message he sends 
out and the recipient to verify the digital signature using the corresponding sender's public key. 

Each service provider is allocated space for the number of public keys used by the service 
provider. If the SP uses the same public/private key pair for both incoming messages and 
1 5 signing of outgoing messages, then one public key is enough. If the SP uses different key pairs 
for receiving and signing messages, then both of the SP's public keys are required in the SPDA. 

In an alternative embodiment of the invention, more than two public/private key pairs may 
be required and used by a service provider for even greater security. 

When an EC holder is issued a new financial or non-financial instrument, the issuing 
20 institution or a trusted third party will load the needed information comprising a record into an 
available slot. The information in the slot can be erased when the service provider account is 
closed. Some of the information in a slot can be read and modified during a transaction, e.g. an 
account balance. Some information such as account number is write protected, but can be read. 
Some information such as a private key is both read and write protected. The access conditions 
25 600 contain security information such as PINs, biometric data, etc., that an EC user must submit 
to open the card for use or to gain access to the information stored on the card. 

Traditional Personal Identification Numbers (PINs) or other security measures such as 
biometrics data are used to protect the EC. Biometrics involves the measurement of a 
cardholder's biological traits, such as physical traits and behavioral traits. A biometric system 
30 may measure an individual's fingerprints, hand-geometry, hand writing, facial appearance, 
speech, physical movements, keyboard typing rhythms, eye features, breath, body odor, DNA, 
or any other physical attribute of the cardholder. The functions provided by an EC can be 
activated only after all the access conditions have been satisfied. Each service provider residing 
on the card can optionally implement other access conditions. 
35 Figure 4 shows the format of the service provider data area of a preferred embodiment of 

the invention. Each service provider's information is allocated an entry in the table, which can 
be protected by additional access conditions. The PIN 712 and the miscellaneous data field 714 
allows the service provider to provide extra protection or data field to the instrument it supports. 
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The name field 702 contains the names of the service providers, which can be used by the 
cardholder at the beginning of an online transaction to initially select the applicable service 
provider for a transaction. The key type field 704 specifies the type of key the service provider 
chooses to use, secret key, public key, etc. The key value 706 and account information fields 
708 contain information unique to each service provider. The card type field 710 specifies the 
type of instrument a service provider supports. 

In the preferred embodiment of the invention, the on-card Operating System (COS) 
provides some fundamental services for the cardholder. Following is a list of general functions 
which can be performed by the COS: 

(1) Traditional OS functionality such as Memory management, task management, etc 

(2) External communication-read/write of user data and communication protocol handling. 

(3) Loading and updating of on-card cardholder information. 

(4) User PIN changes. 

(5) Service Provider Data Area management-such as loading and updating of individual service 
provider information, SPDA access control, etc. 

The COS will also provide support during various stages of a transaction. For example, the 
COS can handle the SP selection at the beginning of a transaction and record the transaction into 
a log file when the transaction has been completed. An embodiment of the invention may 
implement one of the following two design approaches to the COS or a hybrid of the two design 
approaches: 

(1 ) Most of the intelligence can be put into the COS whereby the COS supports most of the EC 
functionalities. Consequently, each on-card service provider area relies on the COS to carry 
out the transaction with the merchant and the SP. In this approach, the COS can provide 
a uniform interface with the outside world for all on-card SPs and efficiently carries out the 
transaction once a SP has been selected. 

(2) Alternatively, the COS can be a pool of general services each on-card SP can utilize. Each 
SP data area can contain applets, which have the intelligence to carry out a transaction with 
the merchant and the SP. In this approach, the SP has more opportunity to implement its 
own unique feature when performing a transaction. 

Figure 5 shows how digital signatures are used in the preferred embodiment of the 
invention. A sender of a message first prepares and sends the data portion of a message M 900 
through a one way hash algorithm, H(*) 902. The output from the hash algorithm is called the 
message digest MD of message M 903. The MD is then encrypted, E(*) 904, i.e. digitally signed, 
using the sender's private key (Pri). The result is called the digital signature DS of a message M. 
The DS is then combined with the original message M 900 and forms a complete message 906 
ready for transmission to a recipient through a network 50. 
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1 The public-key encryption/decryption function can be any of a number of 

encryption/decryption functions. RSA, which takes its name from the first initials of RSA 
developers' last names (Ronald Rivest, Adi Shamir, and Len Adelman), is just one example of 
a public-key encryption/decryption method, which can be used in an embodiment of the 

5 invention. 

When the intended recipient receives the message from a network 50, he first separates the 
data portion of the message M 900 from the digital signature 912 combined with it. The 
recipient then runs the data portion of the message M 900 through the same hash algorithm 910 
that was used to encode the data portion of message M 900, and consequently obtains a message 
10 digest MD A 91 1 of M. The recipient then decrypts D(*) 908 using the EC's public key, the 
digital signature 912 contained in the original message using the sender's public key and 
recovers the original message digest, denoted here as MD 909. MD 909 is compared with the 
new calculated MD A 91 1 for correctness. If they are not identical, the original message has been 
corrupted and should be rejected. 

15 

Following is a list of symbols and abbreviations used in the figures 5 through 1 1 : 

Acknowledgement Data EC = A part of the message sent back by the EC to the SP. It notifies the 

SP that the previous message has been successfully received and processed. 

Acknowledgement Data M = A part of the message sent back by the merchant to the SP. It 
20 notifies the SP that the previous message has been successfully received and processed. 

AI EC = Account information of EC holder. 

AI M = Account information of merchant. 

CRYPTO = Cryptogram 

D = Decryption function 
25 D SP „ Pnvate . Key = Decryption using SP's private key. 

DS = Digital signature function. 

DS EC . Private . Key = Digital signature signed by the EC on a message. 
DS M _ Pnvate . Kev - Digital signature signed by the merchant on a message. 
DS sp-Pnvate-Kev = Digital signature signed by the SP on a message. 
30 E = Encryption function. 

E (Data) = Encryption of data under a data encryption key. 
E SP -pk> E sp-Pubi lc -Key = Data encrypted by SP public key 

Eskey-Ec D skey-Ec = Encryption/Decryption using the session key that the SP generated for the EC. 
Eskey-M, D skey . M - Encryption/Decryption using the session key that the SP generated for the 
35 merchant. 

EC = Electronic card, or electronic card equivalent software 

H (M) = Apply a one-way hashing algorithm on M. It generates the message digest (MD) of M. 
KE = Key exchange phase. 
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1 M = Merchant 

MD = Message Digest 

]YU)a == Message Digest produced by message recipient using the message just received as input 
data. 

5 MD EC = The message digest of a message going from EC to SP. 

MD M = The message digest of a message going from merchant to SP. 
MD SP _ M = The message digest of a message going from SP to merchant. 

MD SP . EC = The message digest of a message going from SP to EC which is by passed by 
merchant. 

10 PLAIN TEXT: Transaction data, which can be transmitted without encryption. Plain text can 
be different for different messages and transaction parties. 

PLAIN TEXT EC = Part of the transaction data provided by EC in its outgoing messages. Plain 
text data fields are not security sensitive. Therefore, they are transmitted without encryption. 
Note that the content of this symbol can be different when used in a different message. 
15 PLAIN TEXT M = Part of the transaction data provided by merchant in its outgoing messages. 
Plain text data fields are not security sensitive. Therefore, they are transmitted without 
encryption. Note that the content of this symbol can be different when used in a different 
message. 

PLAIN TEXT SP _ EC = Part of the transaction data provided by SP for EC only in its outgoing 
20 messages. Plain text data fields are not security sensitive. Therefore, they are transmitted without 
encryption. Note that the content of this symbol can be different when used in a different 
message. 

PLAIN TEXT SP . M = Part of the transaction data provided by SP for merchant only in its outgoing 
messages. Plaintext data fields are not security sensitive. Therefore, they are transmitted without 
25 encryption. Note that the content of this symbol can be different when used in a different 
message. 

STD = Sensitive transaction data, which requires encryption during data transmission. 
STD EC = Sensitive transaction digital data provided by EC in its outgoing messages. Note that 
the content of this symbol can be different when used in a different message. 
30 STD M = Sensitive transaction digital data provided by merchant in its outgoing messages. Note 
that the content of this symbol can be different when used in a different message. 
PK = Public key 

EC-PK, PK EC - Public key of the electronic card. 
M-PK, PK M = Public key of the merchant. 
35 SP-PK, PK SP - Public key of the selected service provider. 

Response Data^ = A part of the message sent back by the SP to the EC during the transaction 
phase of a transaction. It can include approval/disapproval data and/or any other relevant data. 
Response Data SP . M = A part of the message sent back by the SP to the merchant during the 
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1 transaction phase of a transaction. It can include approval/disapproval data and/or any other 

relevant data. 
RN = Random number. 

RN EC = Random number generated by the EC and is sent to SP. 
5 RN SP . EC = Random number generated by the SP and is sent to EC. 

RN M ~ Random number generated by the merchant. 

RN SP . M = Random number generated by the SP and is sent to M. 

SP = Financial or non-financial service provider 

TA = Transaction (currency) amount. 
1 0 Transaction Identification Number SP _ EC , TID SP . EC (Transaction ID SP . EC ) = A data field whose value 

is assigned by the SP during the key exchange phase of a transaction. The EC will use this value 

to communicate with the SP during the same transaction. 

Transaction Identification Number SP _ M , TID SP , M (Transaction ID sp _m) = A data field whose value 
is assigned by the SP during the key exchange phase of a transaction. The merchant will use this 
1 5 value to communicate with the SP during the same transaction. 

* = Combine or concatenation of data within an encryption E or a decryption D. 

Figures 6A through 6Q comprise the flowchart for a preferred embodiment of the 
cryptographic system and method. For the purpose of simplifying the description and symbolism 
contained in figures 6A through 6Q, the flowchart assumes that each of the parties involved in 
20 the transaction uses one key pair. In another embodiment of the invention, two public key pairs 
may be used, in which case, both public keys need to be exchanged. 

The preferred embodiment of the invention consists of two distinct phases: the key 
exchange phase and the transaction phase, 

25 PHASE I: KEY EXCHANGE PHASE (HANDSHAKE PHASE) 

The EC cardholder inserts the EC into a card read/write device or starts the EC equivalent 
software and enters a PIN number and/or satisfies the access conditions 1 10 to use the EC card. 
The entered security information conditions is compared 1 12 with the on-card information 114 
to verify that user is authorized to use the EC. If the security information does not match the 

30 card security information, then the request to use the card is rejected 116. Otherwise, the card 
is unlocked 1 18 for use. Once the card is unlocked, the user can request the list of the on-card 
SPs available for selection and make a selection 120 by issuing an SP selection command to the 
EC. Once the SP is selected, the EC proceeds to start the key exchange (KE) with the SP. The 
public key of the selected SP, represented by the symbols SP-PK and PK SP is obtained from the 

35 EC's SPDA and is used to encrypt messages that will be sent to the SP. 

The main purpose of the KE is to securely send the cardholder's public key, PK EC 126 and 
an EC random number, RN EC 124 to the SP. The SP response to the EC is to assign a session key 
and a transaction ID to the EC, which will be used by the EC to communicate with the SP for the 
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1 rest of the transaction. To format the KE message, the EC generates a random number, RN EC 

124, concatenates it with the EC's public key, PK EC 126, and EC sensitive transaction data 
STD EC 128 relevant to the transaction and/or required by the SP. The EC encrypts them 122 
using the SP's public key, PK SP , retrieved from the SPDA 120. The resulting EC cryptogram, 

5 E ES . PK (RN EC *PK EC *STD EC ), is then combined 130 with the plain text portion of the message, 

PLAIN TEXT EC 132, if any, to form an EC combination message, PLAIN TEXT EC *E SP _ 
PK (RN EC *PK EC *STD EC ). The EC's public key PK EC 126 may be placed in the plain text PLAIN 
TEXT EC instead of being encrypted when forming the EC combination message. 

Only sensitive data is encrypted. Non-sensitive response data is included in the plain text. 

10 Only the SP is able to read the sensitive data. In a multi-party transaction, the SP has full access 
to the sensitive information of all the participants. 

The resulting EC combination message is then sent through a hashing algorithm 134 to form 
a hash message, which is the EC message digest MD EC . The EC message digest MD EC is 
digitally signed by the EC 136 using the EC private key 138 to form a digitally signed message 

15 DS EC . Private . Key . The digitally signed message DS EC . Pnvate . Key is then combined 140 with the EC 
combination message. The combination of the plain text PLAIN TEXT EC cryptogram 
CRYPTO EC and the digital signature DS EC . Pnvate . Key is the KE message from the EC and is sent to 
the merchant 158 through a network. Plain text includes all the transaction data fields that are 
not sensitive in nature and therefore can be transmitted in a clear, discernable form; they do not 

20 need to be encrypted. These data fields are different for each message and are defined by the 
transacting parties. 

To communicate with the SP, the merchant goes through essentially the same steps to 
format its own KE message with the SP as the EC goes through to format the EC's KE message 
with the merchant. The cardholder and the merchant do not communicate with the SP 

25 individually, but through a combined message. Consequently, there will be no need to exchange 
any confidential financial information between the cardholder and the merchant. The merchant 
prepares his device for the transaction 142 and selects from his own SPDA, which resides within 
the merchant's device, the same SP as the EC cardholder has selected for the transaction 144. 
The public key of the SP, represented by the symbols SP-PK and PK SP is obtained from the SP's 

30 SPDA and is used to encrypt messages that will be sent to the SP. 

To format its own KE message, the merchant generates a random number, RN M 148, 
concatenates it with the merchant's public key, PK M 150, and the merchant's sensitive 
transaction data STD^ Sensitive transaction data is data that is relevant to the transaction and/or 
required by the SP 152. The merchant encrypts 146 the combined data using the public key of 

35 the service provider, PK SP . The resulting cryptogram is then combined 154 with the plain text 
portion PLAIN TEXT M 156 of the message, if any, to form a merchant combination message. 
The merchant's public key PK M 1 50 may be placed within the plain text PLAIN TEXT M instead 
of being encrypted when forming the merchant combination message PLAIN TEXT M *E SP _ 
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1 PK (RN M *PK M *STD M ). 

The merchant combination message [PLAIN TEXT M *E SP . PK (RN M *PK M *STD M )] is further 
combined 158 with the EC's KE message {[PLAIN TEXT EC *E SP . PK (RN EC *PK EC *STD EC )]*DS EC . 
private-Key) to form the data Portion of the KE message for both the merchant and the EC, i.e., the 

5 EC-merchant combination message {[PLAIN TEXT EC *E SP . PFC (RN EC *PK EC *STD EC )]*DS EC . Pnvate . 

Key}* [PLAIN TEXT M *E SP „ PK (RN M *PK M *STD M )]. The EC-merchant combination message is sent 
through a hashing algorithm 160 to form a hash message, which is the merchant message digest 
MD M . The merchant message digest MD M is digitally signed 162 by the merchant using the 
merchant's private key 164 to form a merchant digitally signed message DS M . Pnvate Key . The 

10 merchant digitally signed message DS M . Pnvate Key is then combined 166 with the data portion of 
the message, i.e., the EC-merchant combination message to form a key exchange request 
message « { [PLAIN TEXT EC * E SP . PK (RN EC *PK EC *STD EC )] * DS EC _ Pnvate _ Key } * [PLAIN TEXT M 
* E SP . PK (RN M *PK M *STD M ) ] » * DS M . Pnvate . Key for both the merchant and EC. This final message 
is sent to the SP through a network. Figure 7 represents the final format and content of the key 

1 5 exchange request message from a merchant to an SP. 

In the preferred embodiment of the invention, the merchant does not check the MD of the 
EC's request message MD EC because the EC encrypts his public key. However, in an alternate 
embodiment of the invention, if the EC chooses not to encrypt his public key then the merchant 
can optionally check the EC's MD before passing it to the SP. In either the case where the EC 

20 encrypts his public key or where the EC does not encrypt his public key, for enhanced security 
and to avoid possible processing errors by the merchant, the SP can still check the EC's MD. 
When the merchant receives a combination response from the SP for both himself and the EC, 
the merchant does not have to check the MD for the EC since it is part of the overall message 
formed by a single originator - the SP. The merchant only needs to check the MD of the overall 

25 message he receives from the SP. 

When the SP receives the KE request message, the SP first separates 1 68 the data portion 
of the KE request message from the DS and feeds the data portion of the KE request message 
into a one-way hash algorithm to recalculate the message digest, which becomes MD M . The SP 
then separates the merchant's plain text PLAIN TEXT M , cryptogram CRYPTO M , digital 

30 signature DS M _ Pnvate _ Key and the EC's KE request message PLAIN TEXT EC *CRYPTO EC 
*DS EC . Private . Kev . Using its own private key, the SP decrypts merchant's cryptogram 170 and 
recovers, among other information, the merchant's random number RN M 148 and the merchant's 
public key PK M 150. The SP then uses the recovered PK M to decrypt the digital signature signed 
by the merchant DS M _ Private _ Key and recovers the MD M for the merchant's KE message. The SP 

3 5 compares 1 72 the newly hashed MD A M 1 68 with the MD M 1 70 recovered by decrypting the DS 
from the original KE message. If there is a discrepancy between MD A M and MD M found, then 
the KE message has been corrupted and is therefore rejected 1 74. If MD A M and MD M match, then 
the SP separates the data portion of the EC's KE request message from the DS and feeds the data 
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1 portion of the EC's KE request message into a one-way hash algorithm to recalculate the 

message digest (MD A EC ). The SP then separates the EC's plain text PLAIN TEXT EO if any, 
cryptogram CRYPTO EC , and digital signature DS EC _ Private Key , in the data portion of the EC's KE 
request message 176. Using its own private key, the SP decrypts EC's cryptogram and recovers, 

5 among other information, EC's random number RN EC and EC's public key PK EC . The SP then 

uses the recovered PK EC to decrypt the digital signature signed by EC and recovers the MD EC for 
EC's KE message. In the step 178, SP compares the newly hashed MD A EC 176 with the MD EC 
recovered by decrypting the DS from the original KE message. If there is any discrepancy 
found, the KE message has been corrupted and is therefore rejected 1 80. Otherwise, SP is ready 

1 0 to send a KE response message back to merchant and EC. 

To format the KE response message for the EC, the SP generates a random number, RN SP _ EC 
184, and a session key Skey EC 186 for the EC, combines them with the EC generated random 
number, 188 RN EC , service provider sensitive transaction data STD SP _ EC 190 and encrypts them 
192 using the EC's public key PK EC . The resulting cryptogram, 

15 E EC _p K (RN EC *RN SP . EC *Skey EC *STD SP . EC ), is combined 196 with a transaction identification 
number, TIEW 194 assigned to the EC by the SP and plain text, PLAIN TEXT SP . EC 195, if any, 
to form the data portion of the response message for the EC. The SP runs this data through a 
hash algorithm to calculate the message digest MD SP . EC 198. Using its own private key 202, the 
SP creates a digital signature DS SP . Pnvate . Key 200 for the response message by digitally signing the 

20 message digest MD SP . EC . After combining 204 the data portion of the message with the newly 
calculated DS SP _ Private _ Key , the SP's KE response message for the EC is complete, 
[TID SP . EC *PLAIN TEXT S p_ EC *E EC _p K (^ 

To format the KE response message for the merchant, the SP generates a random number 
RN SP . M 208 and a session key Skey M 2 1 0 for the merchant and combines them with the merchant 

25 generated random number RN M 2 1 2, sensitive transaction data STD SP . EC 2 1 4 and encrypts them 
206 using the merchant's public key PK M recovered in 170. The resulting cryptogram is 
combined 216 with a transaction identification number, TID SP . M 218, assigned to the merchant 
by the SP and plain text, PLAIN TEXT SP . M 220, if any, to form the data portion of the response 
message for merchant. The resulting combination message, TID SP . M *PLAIN 

30 TEXT SP . M *E M . PK (RN SP . M *RN M *Skey M *STD SP . M ) is further combined 222 with the KE response 
message for the EC, [TID SP _ EC * PLAIN TEXT SP . EC *E EC . PK (RN SP . EC *RN EC *Skey EC *STD EC )]*DS 
Private-Key, to form the data portion of the SP's final KE response message, [TID SP _ EC * PLAIN 
TEXW*^ TEXT SP . 
M *E M . PK (RN SP . M *RN M *Skey M *STD SP . M )]. The SP runs the data portion through a hash algorithm 

35 to calculate the message digest 224. Using its own private key 228, the SP creates a digital 
signature, DS SP . Pnvate . Key 226, for the response message by digitally signing the message digest. 
After combining 230 the data portion of the message with the newly calculated DS 226, the KE 
response message for both the EC and the merchant is complete. The response message 
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1 «{[TID SP . EC *PLAIN TEXT S p_ ec *(Eec_p K *RN^^^ 

Key }*[TID SP . M *PLAIN TEXT SP _ M *E M _ PK (RN SP _ M *RN M *S^ is sent 

back to the merchant through a network. Figure 8 depicts the final format and content of the 
combined KE response message from the SP to the merchant. 

5 When the merchant receives the KE response message 232, the merchant first separates the 

DS SP . Private _ Key? which was signed by the SP, and then feeds the data portion of the combined KE 
response message into a one-way hash algorithm to recalculate the message digest MD A SP . M . The 
merchant then separates the data portion of the SP's KE response message, i.e., TID SP _ M , PLAIN 
TEXT SP _ M , CRYPTO SP _ M , [(TID SP _ EC * PLAIN TEXT SP . EC *CRYPTO S p. EC )]*DS S p. Pnvate . Ker The 

10 merchant uses SP's public key (selected from 144) to decrypt the digital signature DS SP . Pnvate . Key 
to recover the message digest MD SP . M . The merchant compares 234 the newly hashed MD A SP . M 
with the MD EC If there is any discrepancy between MD A SP . M and MD SP . M , the KE response 
message has been corrupted and is therefore rejected 236. If MD A SP . M and MD SP . M match, then 
the merchant identifies the part of the response message which is meant for him and decrypts the 

15 cryptogram CRYPTO SP . M 238 using his own private key. The merchant should be able to 
recover the original random number RN M (of 148) that he sent to the SP in the KE request 
message. The merchant compares 240 the recovered random number RN M (of the step 238) with 
the original random number RNM. If they are not equal, then the message has been corrupted 
and the message is rejected 242. Since the random number RN M can only be recovered by the 

20 SP using the correct SP private key, it is assured that the sender of the message is indeed the 
selected SP. The merchant then forwards the EC's KE response message [(TID SP _ EC * PLAIN 
TEXT SP . EC *CRYPTO SP . EC )]*DS SP . Pnvate . Key to the EC and prepares for the transaction phase of the 
transaction. 

When the EC receives the KE response message 260, the EC first separates the DS SP _ Private _ 
25 Key wh ich was signed by the SP, and then feeds the data portion of the KE response message for 
the EC into a one-way hash algorithm producing a MD A SP . EC . The EC then separates the data 
portion of the message, i.e., TID SP _ EC , PLAIN TEXT SP . EC , CRYPTO SP _ EC , DS SP 

-Private-key* 

uses SP's public key (selected in 120) to decrypt the digital signature DS SP _ Private _ key message and 
recovers the message digest MD SP . The EC compares 262 the newly hashed MD A SP . EC (in 260) 

30 with the MD SP . EC recovered by decrypting the DS SP . Private . key from the KE response message for 
EC. If there is any discrepancy between MD A SP . EC and MD SP . EC found, the KE response message 
for the EC has been corrupted and is therefore rejected 264. If MD a sp _m and MD SP . M match, the 
EC identifies the part of the response message which is meant for him and decrypts 266 the 
cryptogram CRYPTO SP _ EC which is contained in the message, using his own private key. The 

35 EC should be able to recover the original random number RN EC (of 1 24) that was sent in the EC 
KE request message. The EC compares 268 the recovered random number RN EC (of 266) with 
the original random number RN EC (of 124). If the random numbers are not equal, then the 
message has been corrupted and the message is rejected 270. Since only the SP using the correct 
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1 SP private key can recover the random number RN EC? this serves to ensure that the sender of the 

message is indeed the selected SP. The EC prepares for the transaction phase of the transaction. 

There will be a predefined timeout period set in the EC and the merchant. During a 
transaction, if a response message is not received within a timeout period, the EC and the 

5 merchant will consider the transaction aborted and will either retry or start the recovery process. 

After successful completion of the KE message exchanges, the SP has EC's public key and 
the merchant's public key. At this point, both the EC and the merchant has a random number, 
a transaction ID, and a session key from the SP. The EC and the merchant must send the two 
random numbers recovered from the KE response message back to the SP to complete the key 

1 0 exchange phase of the transaction. This can be done in two ways. The random numbers can be 
sent back through a confirmation message from both the EC and the merchant. Or the random 
numbers can be sent back as part of the next message going out from the EC and the merchant 
to the SP, such as a transaction message. The second method is simpler and is described in phase 
II below. The random numbers are used only once to ensure the correctness of the key exchange 

15 between the SP and merchant, and the SP and EC. Once the session keys and transaction 
identification number have been established, the random number are no longer be used. 

PHASE II: TRANSACTION PHASE 

During the transaction phase, the merchant and the EC each sends their own account 

20 information such as an account number and other transaction related data such as transaction 
amount, request for approval or other processing, to the SP. Again, the EC and the merchant talk 
to the SP individually but through combined messages and the merchant is responsible for 
combining the messages and sending them as one message to the SP. 

The EC first forms the transaction message by concatenating the random number RN SP _ EC 

25 274 from the SP and the EC's account information with the selected SP, AI EC 276, transaction 
amount TA 280 and any other sensitive data 278 relevant to the transaction and/or required by 
the SP. The EC encrypts 272 them using the session key Skey EC assigned by the SP. The Skey EC 
is a secret key and uses a cryptographic algorithm different from the cryptographic algorithm 
used for the public key encryption. The resulting cryptogram CRYPTO EC , i.e., Skey EC (RN SP . 

30 EC *STD EC * AI EC *TA), is then combined 282 with the transaction ID TID SP _ EC 284 and the plain 
text PLAIN TEXT EC 286, if any, to form the data portion of the EC's transaction message, TID SP . 
EC *PLAIN TEXT EC *CRYPTO EC . The data portion 282 is fed into a one-way hash algorithm 288 
to calculate the message digest MD EC and the MD EC is then digitally signed 290 by the EC's 
private key 292. The resulting digital signature 290 is combined with the data portion of the 

35 message (from 282) 294 to form EC's transaction request message and then sent to the 
merchant, [TID SP _ EC *PLAIN TEXT EC *Skey EC (RN SP . EC *STD EC *AI EC *TA)]*DS 

EC-Pnvate-Kev* 

The merchant goes through essentially the same steps to form his transaction message. The 
merchant forms his transaction message by concatenating 246 the RN SP . M from the SP and the 
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1 merchant's account information with the selected SP, AI M 248, transaction amount TA 252 and 

any other sensitive data STD M 250 relevant to the transaction and/or required by the SP. The 
merchant encrypts them 244 using the session key Skey M assigned by the SP. The session key 
Skey M is a secret key and is created using a different cryptographic algorithm, such as DES, from 

5 the cryptographic algorithm used for public key encryption. The session key Skey M is used to 

perform the encryption at this point to create the cryptogram CRYPTO M . The resulting 
cryptogram CRYPTO M , i.e., Skey M (RN SP _ M * STD M *AI M *TA), is then combined 254 with the 
transaction ID TID S p. M 256 and the plain text PLAIN TEXT M 258, if any, to form the data portion 
of the merchant's transaction message, TID SP . M *PLAIN TEXT M *CRYPTO M . This data is 

1 0 combined 296 with the EC's transaction request to form the data portion of the final transaction 
request message for the SP, [TID SP _ EC * PLAIN TEXT EC * Skey EC (RN SP _ 
EC *STO EC *AI EC *TA)]*^^ TEXT M * Skey M (RN SP _ M * STD M * AI M *TA)] . 

As before, the merchant feeds his combined data through a one-way hash algorithm 298 to 
calculate the message digest MD M and the MD M is then digitally signed 300 by the merchant's 

1 5 private key 302. The resulting digital signature DS M . Pnvate . Key 300 is combined 304 with the data 
portion of the message (from 296) to form the final transaction request message and is then sent 
to the SP, {[TTD SP _ EC *PLAIN TEXT EC *Skey EC (RN SP _ EC *STO^^ 

M * PLAIN TEXT M *Skey M (RN SP _ M *ST^ Figure 9 depicts the final 

format of the transaction request message. 

20 When the SP receives the transaction request message, the SP first checks 306 the two 

transaction identification numbers, i.e., TID SP . EC and TID SP _ M , sent by the EC and the merchant 
and makes sure they are valid. When either TID SP . M (of 2 1 0) or TID SP . EC (of 1 86) is found invalid 
306, then the message is rejected 308. If the transaction identification numbers are both valid, 
then the SP proceeds to separate the DS M . Private . Key from the data portion of the message and feeds 

25 the data portion of the message, {[TID SP _ EC *PLAIN TEXT EC * Skey EC (RN SP _ 
ec*STDec*AI E c*TA)]*DS^ TEXT M *Skey M (RN SP _ 

M *STD M *AI M *TA)]} into a one-way hash algorithm to calculate the message digest MD A M of 
this message. The SP separates the data portion of the message, i.e., TID SP _ M , PLAIN 
TEXT M ,CRYPTO M , DS M . Pnvate . Key , (TID SP _ EC *PLAIN TEXT EC *CRYPTO EC )*DS EC . Pnvate . Key . The 

30 SP decrypts 310 the DS M . Pnvate . Key using the merchant's public key and compares the newly 
recovered message digest MD M with the message digest just calculated MD A M (from 306). If 
MD A M and MD M are not equal, the message has been corrupted and is rejected 314. If MD A M 
and MD M match, then the SP decrypts 3 1 6 the encrypted portion of the message using the session 
key Skey M (of 210) it assigned to the merchant during the KE phase and recovers the data fields 

35 contained in the encrypted portion. The SP compares 318 the random number RN SP . M the 
merchant sends back in the message with the message the SP sent to the merchant originally, 
RN SP . M (from 208). If the random numbers are not equal, then the merchant has failed the mutual 
authentication test and the message is rejected 320. 
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1 In addition, the SP will verify the EC's account information AI EC and the transaction data 

such as the transaction amount TA. The message is rejected 320 if the AI is no longer valid. It 
is also rejected when the TA from the EC and the TA from the merchant do not match. There 
may be other conditions for invalidating a message. If the account information AI EC and the 

5 transaction are valid, then the SP goes on to verify the EC portion of the message. 

As with the merchant's message, the SP first separates 322 the DS EC . Pnvate . Key from the EC's 
message and feeds the data portion of the EC's message, (TID SP _ EC *PLAIN TEXT EC *CRYPTO EC ) 
into a one-way hash algorithm to calculate the message digest MD A EC of the EC message. The 
SP separates the data portion of EC's transaction request, TID SP _ EC , PLAIN TEXT EC , CRYPTO EC , 

10 DS EC . Private _ Key . The SP decrypts 324 DS EC _ Pnvate _ Key using EC's public key PK EC and recovers 
MD EC . The SP compares 326 the recovered MD EC with MD A EC . If MD A EC and MD EC are not 
equal, the message has been corrupted and is rejected 328. If MD A EC and MD EC match, then the 
SP decrypts 330 the encrypted portion of the EC message using the session key Skey EC (of 186) 
it assigned to the EC during the KE phase and recovers the data fields contained in it. The SP 

1 5 compares 332 the random number RN SP . EC the EC sends back in the message with the random 
number RN SP . EC it sent out to the EC originally (in 184). If the random numbers are not equal, 
then the EC has failed the mutual authentication test and the message is rejected 334. The SP 
will verify the merchant's account information AI M and the transaction data such as the 
transaction amount TA and will reject the message when the account information is invalid or 

20 when the transaction data does not meet the SP's criterion 334. Once the integrity and 
authenticity of the overall message has been established, the SP can process the data contained 
in the message and send a response message back. The random number that is sent back in this 
message completes the mutual authentication between the SP and the merchant, and between the 
SP and the EC. After this message, no exchange of random numbers will be necessary. The SP 

25 can chooses to use the random number as the transaction identification number which the 
merchant and the EC will use in all subsequent messages that they send to the SP. 

As before, the response message contains information for both the EC and the merchant. 
To format the transaction response message for the EC, the SP generates the response data for 
the EC, Response Datas P . EC 338, and encrypts 336 it using the session key Skey EC assigned to the 

30 EC. Only sensitive data is encrypted. Non-sensitive response data is included in the plain text. 
The cryptogram CRYPTO SP . EC , i.e., E Skey _ EC (Response Data SP _ EC ), is combined 340 with the 
transaction identification number TID SP . EC 342 that the SP assigned to the EC (from 194) and the 
plain text that the SP has for EC 344, if any, to form the data portion of the response message for 
the EC, i.e., TID SP _ EC * PLAIN TEXT SP _ EC *E skey _ EC (Response Data SP _ EC ). The data portion of the 

35 message is fed into a hash algorithm 346 to generate a MD SP . EC which is digitally signed 348 by 
the SP using the SP's private key 350. The DS SP . Pnvate . Key is combined 352 with the data portion 
of the response message (from 340) to form the complete response message for the EC, [TID SP . 
EC *PLAIN TEXT SP _ EC *E skey _ EC (Response Data SP . EC )]*DS SP . Private . Key . 
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1 To format the transaction response message for the merchant, the SP generates the response 

data for the merchant, Response Data SP . M 356, and encrypts 354 it using the session key Skey M 
assigned to the merchant (from 210). The cryptogram CRYPTO SP . M , is combined 358 with the 
transaction identification number TTD SP . M assigned to merchant 360 (from 218) and the plain text 

5 PLAIN TEXT SP _ M that the SP has for merchant 362, if any, to form the data portion of the 

response message for the merchant, TID SP . M *PLAIN TEXT SP . M *CRYPTO SP . M . The data is then 
combined 364 with the completed response message for the EC to form the data portion of the 
response message for both the EC and the merchant, [(TID SP . EC * PLAIN TEXT SP . EC *E Skey . 
EC (Response Data SP . EC )]*DS S p. Private . Key *[TID S p. M *PLAIN TEXT SP . M *E .^Response Data SP . 

10 m)1- 

The data is then fed into a hash algorithm 366 to generate a MD SP . M which is digitally signed 
368 by the SP using the SP's private key 370. The DS SP . Pnvate . Key is combined 372 with the data 
portion of the response message for both the EC and the merchant to form the complete response 
message for both the EC and the merchant, «{[TID SP . EC * PLAIN TEXT SP . EC *E skey . EC (Response 

1 5 Data SP . EC )]*DS SP . Pnvate . Key } * [TID SP . M * PLAIN TEXT SP _ M * E Skey _ M (Response Data SP . M )]» DS SP . Pnvate . 
Key . The SP then sends its response message back to the merchant. Figure 10 depicts the final 
format of the transaction response message. 

When the merchant receives the message, the merchant first checks 374 the transaction 
identification number, TID SP . M in the message and makes sure it is valid. If the transaction 

20 identification number is invalid then the message is rejected 376. If the TID SP . M is valid, then 
the merchant separates the DS SP . Private . Key which was signed by the SP from the data portion of the 
message, and then feeds the data portion of the transaction response message «{[TH) SP _ 
EC *PLAIN TEXT SP . EC *E skey . EC (Response Data SP . EC )]*DS SP . Pnvate . 1Cey }*[TID SP . M *PLAIN TEXT SP . 
M *E Skey . M (Response Data SP . M )]» into a one-way hash algorithm producing a MD SP . M . The 

25 merchant separates the data portion of the message into different parts, TID SP . M , PLAIN 
TEXT SP . M , CRYPTO SP . M , DS SP . Pnvate . Key (TID SP . EC *PLAIN TEXT SP . EC *CRYPTO SP . EC *DS SP . Pnvate . 
Key ) and prepares to forward SP's transaction response message to the EC. The merchant 
decrypts 378 the encrypted portion of the SP's message using the session key Skey M assigned 
by the SP during the KE phase and recovers the data fields contained within it. The merchant 

30 then uses SP's public key, PK SP (froml44), to decrypt the digital signature DSspftj^ to 
recover MD SP . M . The merchant compares 380 the newly hashed MD A SP . M (from 374) with the 
recovered MD SP . M If MD A SP . M and MD SP . M do not match, then the transaction response message 
has been corrupted and is therefore rejected 382. If the message digests match, then the 
merchant starts processing the message. As usual, the EC portion of the transaction response 

35 message (TID SP . EC *PLAIN TEXT SP . EC *CRYPTO S p_ EC *DS S p. Private . Key ) is passed to EC. 

When the EC receives the transaction response message, the EC first checks 394 the 
transaction identification number, TID SP _ EC in the message and makes sure it is valid. If the 
transaction identification numbers is invalid, then the message is rejected 396. If the transaction 
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1 identification number is valid, then the merchant separates the DS SP _ Pnvate _ Key which was signed 

by the SP, from the data portion of the transaction response message, and then feeds the data 
portion of the EC transaction response message TID SP _ EC * PLAIN TEXT SP . EC *E skey . EC (Response 
Data SP . EC ) into a one-way hash algorithm producing MD A SP . Ee The EC separates the message 

5 into different parts, TID SP _ EC , PLAINT SP _ EC , CRYPTO SP . EC , DS SP _ Pnvate _ Key . The EC decrypts 398 

the encrypted portion of SP's message using the session key Skey assigned by the SP during the 
KE phase and recovers the data fields contained within it. The EC uses SP's public key (from 
120) to decrypt the digital signature DS SP _ Pnvate . Key and recovers the message digest MD SP . EC . The 
merchant compares 400 the newly hashed MD A SP _ EC 394 with the recovered MD SP . EC . If MD A SP _ EC 

10 and MD SP . EC do not match, then the transaction response message has been corrupted and is 
therefore rejected 402. If the message digests match, then the EC starts processing the message. 

At the end of the transaction, the EC and the merchant can, if required by the SP, send an 
acknowledgement message to the SP to signal that the response message has been correctly 
received and processed. This acknowledgement data can be included as a part of the next 

1 5 message to be sent to the SP, if there are more messages to be exchanged between the SP and the 
merchant and the EC before the transaction ends. Or the acknowledgement data can be a 
message by itself 

To format the acknowledgement message, the EC first encrypts 404 the sensitive part of the 
acknowledgement data, Acknowledgement Data EC , 406, if any, using the session key, Skey EO 

20 thus creating Skey^Acknowledgement Data EC ). The EC combines 408 the resulting cryptogram 
with the transaction identification number TID SP . EC 410 assigned by the SP and the plain text 
PLAIN TEXT EC 412, if any. This forms the data portion of EC's acknowledgement message, 
TID SP . EC *PLAIN TEXT EC * Skey EC (Acknowledgement Data EC ). This combined data is then fed 
into a one-way hash algorithm 414 to generate the MD EC . The resulting MD EC is then digitally 

25 signed 416 by the EC using the EC's private key 41 8 to generate a DS EC _ Pnvate _ Ker The DS ECM >rivate- 
Kev is combined 420 with the data portion of the message (from 408) to form the complete 
acknowledgement message for the EC, [TID SP _ EC *PLAIN TEXT EC *Skey EC (Acknowledgement 
Data EC )]*DS Ec . Pnvate . Key . The acknowledgement message is then sent to the merchant. 

The merchant goes through the same steps to form his own acknowledgement message. To 

30 format the acknowledgement message, the merchant first encrypts the sensitive parts of the 
acknowledgement data, Acknowledgement Data M 386, if any using the session key Skey M 
assigned by the SP to merchant, thus creating Skey M (RN SP . M * Acknowledgement DataJ. The 
merchant combines 388 the resulting cryptogram with the transaction identification number 
TTD SP _ M 390 assigned by the SP, and the plain text PLAIN TEXT M (from 392), if any. This forms 

35 the data portion of the merchant's acknowledgement message, TID SP . M *PLAIN TEXT M * 
Skey M (RN SP „ M * Acknowledgement Data M ). This data portion is further combined 422 with the 
acknowledgement message received from the EC to form the data portion of the combined 
acknowledgement message for the SP, {[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement 
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1 Data EC )]*DS EC . Pnvate . Key }*[TID SP . M *PLAIN TEXT M *Skey M (Acknowledgement Data M )]. The 

merchant feeds the data portion of the combined acknowledgement message for the SP into a 
one-way hash algorithm to generate the message digest MD M . The resulting MD M is then 
digitally signed by the merchant using the merchant's private key 428 to generate DS M _ Pnvate _ Key 

5 426. The DS M . Privatfr * cy is combined 430 with the data portion of the message (from 422) to form 

the final combined acknowledgement message of the EC and the merchant designated for the SP, 
«{[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )]*DS EC . Private . Key }*[TID SP . 
M * PLAIN TEXT M *Ske yM (Acknowledgement Data M )]»*DS M _ Pnvate . Key . This message is then sent 
to the SP. Figure 1 1 depicts the final format of the transaction acknowledgement message. 

10 TID SP . M is the transaction identification number assigned by the SP to the merchant (from 

218) and TID SP . EC is the transaction identification number assigned by the SP to the EC (from 
194). Upon receiving the transaction acknowledgement message, the SP checks 432 the two 
transaction identification numbers, TID SP . M and TID SP _ EC , sent by the EC and the merchant and 
makes sure they are valid. When either TID SP _ M or TID SP . EC is found invalid, then the message 

1 5 is rejected 434. If the transaction identification numbers are both valid, then the SP proceeds to 
separate the DS M . Pnvate . Key from the combined acknowledgement message and feeds the data 
portion of the combined acknowledgement message <<{[TID SP _ EC * PLAIN 
TEXT EC *Skey EC (Acknowledgement Data EC )]*DS EC . Pnvate . ICey } * [TID SP . M *PLAIN 
TEXT M *Skey M (Acknowledgement Data^^ into a one-way hash algorithm to calculate the 

20 message digest MD A M of this message. The SP separates the data portion of the message, TID SP . 
M , PLAIN TEXT M , CRYPTO M , DS M . Pnvate . Key , (TID SP _ EC * PLAIN TEXT EC *CRYPTO EC )*DS EC _ 
pnvate-Ker sp decrypts 436 the DS M . Private . Key using the merchant's public key PK M and 

compares the recovered message digest MD M 432 with the message digest just calculated MD A M 
436. If MD A M and MD M are not equal, then the message has been corrupted and is rejected 440. 

25 If MD A M and MD M match, then the SP decrypts 442 the encrypted portion of the merchant's 
acknowledgement message using the session key Skey M (from 210) that it assigned to the 
merchant during the KE phase and recovers the acknowledgement data contained within it. 

The SP separates 444 the DS EC _ Private _ Key from the EC's acknowledgement message and feeds 
the data portion of the EC's acknowledgement message, TID SP _ EC * PLAIN TEXT EC *CRYPTO EC , 

30 into a one-way hash algorithm to calculate the message digest MD A EC of this message. The SP 
separates the data portion of the EC's acknowledgement message, TID SP _ EC , PLAIN TEXT EC , 
CRYPTO EC , DS EC . Pnvate . Key . The SP decrypts 446 the DS EC _ Pnvate _ Key using the EC's public key 
PK EC and compares 448 the recovered MD EC with the message digest just calculated MD A EC 444. 
If the message digests are not equal, then the message has been corrupted and is rejected 450. 

35 If MD A EC and MD^ match, then the SP decrypts 452 the encrypted portion of the message using 
the session key Skey EC (from 1 86) that it assigned to the EC during the KE phase and recovers 
the acknowledgement data contained within it. This completes the processing of the transaction 
phase of the transaction 454. 
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1 Throughout the transaction, in a preferred embodiment, the EC works with interface 

software provided by Internet browser software such as the Microsoft Explorer or Netscape 
Navigator. In a typical session, the cardholder points his browser to the merchant's URL and 
orders goods or services from the merchant. At the time of payment, the browser will invoke the 

5 EC interface software, which can be built into the browser or included as a plug-in or add-on 

software component, and allow the transaction to proceed. The cardholder can point his browser 
to the URL of any SP member. 

The two-phased transaction described in figure 6A-6Q above is just a specific case of 
applying the two-phased key-exchange-transaction model In the two-phased transaction 

10 described in figures 6A-6Q, the number of parties involved in the transaction is three: the EC, 
the merchant and the SP. The two-phased key-exchange -transaction model is similarly 
applicable to cases where the number of parties involved varies from two to many. In a 
transaction that involves more than three parties, there is only one party that plays the role of the 
SP. All other parties use the public key of the selected SP to perform the initial key exchange 

1 5 and use session keys and transaction Ids assigned by the SP to carry out the transaction. 

The two-phased key-exchange-transaction model is applicable to organization schemes 
wherein: (1) the participants can be arranged with possible routers in series with the service 
provider; or (2) the participants can be arranged with possible routers in a hierarchical 
organization. These additional organization schemes may involve routers, which route messages 

20 to the next level. A level of a hierarchy may be composed of any number of participants and/or 
routers. The next level is the next participant or router that is next in the sequence or hierarchy. 
In a hierarchical organization scheme, the next level includes all possible next participants and 
routers. For the hierarchical organization scheme, the SP establishes the criterion for 
determining the next participant or router to which a message is sent. 

25 A router is a gateway/conduit, which collects the messages from a previous level and 

performs some processing on the messages according to an SP's requirements such as combining 
them, and then forwards the messages to the SP. Each participant need only form his own 
message (data and digital signature) and send it to the next level. A participant combines all the 
messages he receives with his own message and digitally signs the combined message before 

30 sending it to next level. In the hierarchical organization's simplest form, there is only one 
message router, which collects messages from all the other participants and sends the combined 
message to the SP. 

In the series organization, an originator of a transaction is in series with routers and/or 
participants who in turn are in series with a service a service provider 60. In the preferred 
35 embodiment of the invention, each element shown in figure 12 is a participant. In an alternative 
embodiment of the invention, any intermediate element between the originator and the SP can 
be a router. 

An originator conducts a transaction with participants 1 100, 1 120, 1 140 and 1 160 and a 
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1 service provider that have been arranged in series as shown in Figure 12. This is similar to the 

three-party scenario described in figures 6A-6Q except for the fact that now there is more parties 
involved. Note participants 3,4,5,6 . . . n-2 that have been arranged in series 1 1 80. Each of the 
participants prepares his own message, incorporates it with the message he receives from a prior 

5 participant, if any, appends a digital signature with the message, and then sends it to the next 

participant in the line. The combined message is eventually sent to the SP and the SP forms the 
response message accordingly and sends it back through the same path the original request 
message has traveled. 

Figure 13 shows elements arranged in a hierarchical organization scheme, where each 

1 0 element, Xj j to X ; n (n= 1 , 2, 3 , . . . ) 1 200, is a participant of the transaction and not a message 
router, and each element, X ^ Q = 2, 3, 4, . . .; k - 1 , 2, 3, . . .m; m is a variable of type n; m may 
be a different value for different levels of a hierarchy) 1210, can either be a participant or a 
router. The upward pointing bold arrow represents sending a request message 1220. The 
downward pointing arrow represents sending a response message 1230. 

1 5 Each participant collects messages from a number of participants he is responsible for and, 

after combining the messages with his own and forming a new message, sends the new message 
to the next level. A hierarchical organization scheme may include only one participant to as 
many as is required (The most regressive case of the hierarchical scheme is one participant and 
one service provider). Eventually, at the last element before the service provider, X 0 ] where a 

20 is of type n, all messages are combined into one message 1240, which is then sent to the SP 60. 
Again, the SP forms the response message and sends it back through the same route. 

In the case when the SP is not directing the transaction, the members are conducting the 
transaction among themselves using the session key generated by the SP. A transaction can 
occur between two or more members. When there are more than two members involved in the 

25 transaction, the messages can flow from member to member in any order. A member sends a 
transaction request message and receives a transaction response message. A member does not 
necessarily have to receive a transaction response message from the same member that he sent 
the transaction request message. For example, three members in a transaction can be organized 
in a ring and send messages around the ring. A first member can send a transaction request 

30 message to a second member who in turn sends a transaction request message and a transaction 
response message to third member. The third member sends a transaction request message and 
a transaction response message to the first member, and the first member sends a transaction 
response message to a second member. A member receiving a transaction request message 
creates a transaction response message, which eventually will be sent to the member who sent 

35 the transaction request message. 

During the key exchange phase, the SP obtains the public keys of all the transaction 
participating members. The SP sends to each participating member, the other members' public 
keys prior to the participating members conducting a transaction among them. The transaction 
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1 request messages and the transaction response message include plain text, if any, a cryptogram, 

and a digital signature of the sending party. 

In the case when the SP needs to act as the surrogate-certificate for the EC and/or the 

merchant in order to deal with a certificate-based external system, the SP shields the EC and/or 
5 the merchant from the operation of the external interface. The SP only returns to the EC and/or 

the merchant, the information needed to complete the transaction with the EC and/or the 

merchant. 

While there have been described herein what are considered to be preferred and exemplary 
embodiments of the present invention, other modifications of the invention shall be apparent to 

1 0 those with ordinary skill in the art. Therefore, it is desired to be secured in the appended claims 
all such modifications and extensions as fall with within the true spirit and scope of the 
invention. The invention is to be construed as including all embodiments thereof that fall within 
the scope of the appended claims and the invention should only be limited by the appended 
claims below. In addition, one with ordinary skill in the art will readily appreciate that other 

1 5 applications may be substituted for those set forth herein without departing from the spirit and 
scope of the present invention. 
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CLAIMS: 

1 . A system for electronic transactions comprising: 
an electronic card having, 

a cryptographic service for encryption and decryption, 

a data area for storing information, and 

a data area for storing cardholder with the service provider member terminal; 
a service provider member terminal responsive to the electronic card; and 

a service provider terminal in communication service provider information. 

2. The system of claim 1 wherein the electronic card is a physical card. 

3. The system of claim 1 further comprising software having the electronic card. 

4. The system of claim 1 wherein the electronic card further comprises a card operating 
system for loading and updating cardholder information, changing a PIN, and managing the 
service provider data area. 

5. The system of claim 1 wherein the electronic card performs external communication 
read/write operations, and communication protocol handling. 

6. The system of claim 1 wherein the electronic card further comprises software to manage 
the electronic card. 

7. The system of claim 1 wherein the data area for storing service provider information 
comprises a service provider record comprising: 

a name field indicating the service provider; 
a key value; and 

an account information field containing information unique to each service provider. 

8. The system of claim 1 wherein the electronic card further comprises application software. 

9. The system of claim 1 wherein the electronic card further comprises applets. 

10. The system of claim 1 further comprising an external system wherein the service provider 
terminal communicates with the external system. 

1 1 . The system of claim 7 wherein each service provider record further comprises a card type 
field specifying the type of instrument a service provider supports. 
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1 1 2. A method of conducting an electronic transaction using an electronic card comprising the 

steps of: 

generating a session key at the service provider; 

exchanging keys by sending a key from a member to a service provider and sending a session 
5 key from the service provider to the member; and 

using the session key to conduct a transaction. 

13. The method of claim 12 wherein the step of exchanging keys comprises the steps of: 
sending a key exchange request message from a member to a service provider; and 

1 0 formatting a key exchange response including the session key for a member and sending the 

key exchange response to a member. 

14. The method of claim 12 wherein the step of using a session key to conduct a transaction 
comprises the steps of: 

1 5 formatting a member transaction request message using the session key and sending it to the 

service provider; and 

formatting at the service provider, a transaction response message for the member and 
sending the transaction response message to the member. 

20 15. The method of claim 1 2 wherein the step of using a session key to conduct a transaction 

comprises the steps of: 

formatting by a first member, using the session key, a transaction request message, the 
transaction request message including a digital signature of the first member, and sending the 
transaction request message to a second member; and 
25 formatting by a second member, using the session key, a transaction response message, the 

transaction response message including a digital signature of the second member, and sending 
the transaction response message to the first member. 

16. The method of claim 12 wherein the step of using a session key to conduct a transaction 
30 comprises the steps of: 

formatting by a first member, using the session key, a transaction request message, the 
transaction request message including a digital signature of the first member, and sending the 
transaction request message to an intermediate member; and 

formatting by an intermediate member, using the session key, a transaction response 
35 message, the transaction response message including a digital signature of the intermediate 
member, and sending the transaction response message to a final member; 

formatting by a final member, using the session key, a transaction response message, the 
transaction response message including a digital signature of the final member, and sending the 
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1 transaction response message to the first member. 

17. The method of claim 12 wherein the step of exchanging keys comprises the steps of: 
sending a key exchange request message from the electronic card to a merchant terminal; 

5 combining at the merchant terminal, a merchant key exchange request message with the 

electronic card's key exchange request message and sending the combined key exchange request 

message to a service provider; 

formatting a key exchange response including the session key for the merchant terminal, 

formatting a key exchange response including the session key for the electronic card, combining 
10 the key exchange responses into a combined key exchange response and sending the combined 

key exchange response to the merchant terminal; and 

separating at the merchant terminal, the key exchange response for the merchant from the key 

exchange response for the electronic card system, and forwarding the key exchange response for 

the electronic card to the electronic card. 

15 

18. The method of claim 12 wherein the step of using a session key to conduct a transaction 
comprises the steps of: 

formatting the electronic card's transaction request message using the session key and 
sending it to the merchant terminal; 
20 formatting at the merchant's terminal, using the session key, the merchant transaction request 

message combining the received transaction request message with the merchant transaction 
request message and sending the combined transaction request message to the service provider; 

formatting by the service provider, using the session key, a transaction response message for 
the merchant, a transaction response message for the electronic card system, and combining the 
25 transaction response messages into a combined transaction response message and sending the 
combined transaction response message to the merchant terminal; and 

separating at the merchant terminal, the transaction response message for the merchant from 
the transaction response message for the electronic card, and forwarding the transaction response 
message for the electronic card system to the electronic card. 

30 

19. The method of claim 12 wherein when the service provider is directing the transaction, 
only the service provider can read sensitive transaction data within a message sent from a 
member. 

35 20. The method of claim 12 wherein when the service provider is not directing the 

transaction, only the service provider can read sensitive transaction data within a message sent 
from a member during the key exchange phase. 
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1 21. The method of claim 13 wherein the key exchange response further comprises public 

keys for every member involved in a transaction. 

22. The method of claim 13 wherein a key exchange request message includes a member 
5 generated random number within the encrypted part of the key exchange message. 

23. The method of claim 13 wherein a key exchange request message includes a member 
generated digital signature. 

10 24. The method of claim 13 wherein a key exchange request message from a member 

includes a cryptogram comprising: 

a random number of the member; and 
sensitive data of the member. 

15 25. The method of claim 14 wherein a transaction message includes a random number within 

the encrypted part of the transaction message. 

26. The method of claim 14 wherein a transaction message includes a digital signature of a 
sending party. 

20 

27. The method of claim 14 wherein only the service provider can read sensitive transaction 
data within a transaction message. 

28. The method of claim 14 further comprising the steps of: 

25 formatting at the member, using the session key, a transaction Acknowledgement message 

and sending the transaction Acknowledgement message to the service provider. 

29. The method of claim 1 8 further comprising the steps of: 

formatting at the electronic card, using the session key, a transaction Acknowledgement 
30 message and sending the transaction Acknowledgement message to the merchant; and 

formatting at the merchant's terminal, using the session key, the merchant transaction 
Acknowledgement message, combining the received transaction Acknowledgement message 
with the merchant transaction Acknowledgement message and sending the combined transaction 
Acknowledgement message to the service provider. 

35 

30. The method of claim 24 wherein the key exchange request message further comprises 
plain text. 
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1 31. The method of claim 24 wherein the key exchange request message further includes a 

digital signature of a member. 

32. The method of claim 24 wherein the cryptogram further comprises a public key of the 
5 member. 

33. The method of claim 25 wherein a transaction message includes a digital signature of a 
sending party. 

10 34. A method of sending a key exchange message comprising the steps of: 

satisfying electronic card access conditions by an electronic cardholder; 
selecting a service provider by the electronic cardholder; 
generating an electronic card random number by the electronic card; 

encrypting by the electronic card with a service provider's public key, a random number, an 
15 electronic card public key, and electronic card sensitive transaction data to form an electronic 
card cryptogram: 

combining by the electronic card the electronic card cryptogram with plain text, if any, to 
form an electronic card combination message; 

applying a hashing algorithm to the electronic card combination message to form an electronic 
20 card message digest; 

digitally signing by the electronic card, the electronic card message digest using the 
electronic card private key to form an electronic card digitally signed message; 

combining by the electronic card, the electronic card combination message with the 
electronic card digitally signed message to form a key exchange message from the electronic 
25 card; and 

sending the electronic card key exchange message from the electronic card to a merchant 
through a network. 

35. The method of claim 34 further comprising the steps of: 
30 generating a merchant random number by a merchant device; 

encrypting by the merchant device with a service provider's (SP's) public key, a merchant 
random number, a merchant public key, and merchant sensitive data to form a merchant 
cryptogram; 

combining by the merchant device, the merchant cryptogram with plain text, if any, to form 
35 a merchant combination message; 

combining by the merchant device the electronic card (EC) key exchange message with the 
merchant combination message to form an EC-merchant combination message; 

applying a hashing algorithm to the EC-merchant combination message to form a merchant 
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1 message digest; 

digitally signing by the merchant device, the merchant message digest using the merchant's 
private key to form a merchant digitally signed message; 

combining by the merchant, the EC-merchant combination message with the merchant 
5 digitally signed message to form a merchant key exchange request message from the merchant; 

and 

sending the merchant key exchange request message from the merchant to a service provider 
through a network. 

10 36. A key exchange request message comprising: 

electronic card plain text; 

electronic card cryptogram, encrypted with a service provider public key, comprising an 
electronic card random number, an electronic card public key, and electronic card sensitive 
transaction data; 

15 an electronic card digital signature of the electronic card plain text and the electronic card 

cryptogram; 

merchant plain text; 

merchant cryptogram, encrypted with the service provider public key, of a merchant random 
number, a merchant public key, and merchant sensitive transaction data; and 
20 a merchant digital signature of the merchant plain text and the merchant cryptogram. 

37. A key exchange response message comprising: 
service provider (SP) plain text for the electronic card (EC); 
SP transaction identification number for the EC; 

25 SP cryptogram for the EC, encrypted with the EC public key, of the EC random number, an 

SP random number for the EC, a session key, and SP sensitive transaction data for the EC; 

an SP digital signature of the SP plain text for the EC, the SP transaction identification 
number for the EC; and the SP cryptogram for the EC; 
SP plain text for the merchant; 
30 SP transaction identification number for the merchant; 

SP cryptogram for the merchant encrypted with the merchant public key, of the merchant 
random number, an SP random number for the merchant, a session key, and SP sensitive 
transaction data for the merchant; and 

an SP digital signature of the SP plain text for the merchant, the SP transaction identification 
35 number for the merchant; and the SP cryptogram for the merchant. 

38. A method of conducting an electronic transaction among multiple parties arranged in 
series comprising the steps of: 
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1 sending a key exchange request message from an electronic card to a first party where the 

first party is a message router or participant; 

sending the key exchange request message from the first party to a next party if the first party 
is a router; 

5 combining a first party's key exchange request message with the electronic card's key exchange 

request message and sending the combined key exchange request message to a next party if the 
first party is a participant; 

sending the key exchange request message to a next party if the current party is a message 

router; 

10 combining a current party's key exchange request message with a last party's key exchange 

request message and sending the combined key exchange request message to a next party, if the 
current party is a participant; 

formatting, by the service provider, into one message, a key exchange response for each 
participant and sending the message in reverse order of the path for sending the key exchange 
1 5 request message to the service provider; and 

separating, by every participant, the key exchange response for itself from the key exchange 
responses for the other participants, and forwarding the remaining key exchange responses to the 
other participants in reverse order of the path for sending the key exchange request message to 
the service provider, until the electronic card receives its key exchange response. 

20 

39. A method of conducting an electronic transaction among multiple parties arranged in 
series comprising the steps of: 

sending a transaction request message from an electronic card to a first party where the first 
party is a message router or participant; 
25 sending the transaction request message from the first party to a next party if the first party 

is a router; 

combining a first party's transaction request message with the electronic card's transaction 
request message and sending the combined transaction request message to a next party if the first 
party is a participant; 

30 sending the transaction request message to a next party if the current party is a message 

router; 

combining a current party's transaction request message with a last party's transaction 
request message and sending the combined transaction request message to a next party, if the 
current party is a participant; 
35 formatting, by the service provider, into one message, a transaction response for each 

participant and sending the message in reverse order of the path for sending the transaction 
request message to the service provider; and 

separating, by every participant, the transaction response for itself from the transaction 
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1 responses for the other participants, and forwarding the remaining transaction responses to the 

other participants in reverse order of the path for sending the transaction request message to the 
service provider, until the electronic card receives its transaction response. 

5 40. A method of conducting an electronic transaction among multiple parties arranged in a 

hierarchical organization comprising the steps of: 

sending a key exchange request message from an electronic card to a first party where the 
first party is a message router or participant; 

sending the key exchange request message to a next party X jk (j = 2, 3, 4, ...; k = 1, 2, 3, 
10 ... m; m is a variable of type n; n= 1 , 2, 3 , . . . ; m can be different values for different values of 
j) if the first party is a message router; 

combining a first party's key exchange request message with the electronic card's key 
exchange request message and sending the combined key exchange request message to a next 
party X jk if the first party is a participant; 
1 5 sending the key exchange request message to the next party X jik if a current party X jk is a 

message router; 

combining a current party X jk 's key exchange request message with the last party's key 

exchange request message and sending the combined key exchange request message to the next 

party X jk , if the current party X jtk is a participant; 
20 formatting, by the service provider, into one message, a key exchange response for each 

participant and sending the message in reverse order of the path for sending the key exchange 

request message to the service provider; and 

separating, by every participant, the key exchange response for itself from the key exchange 

responses for the other participants, and forwarding the remaining key exchange responses to the 
25 other participants in reverse order of the path for sending the key exchange request message to 

the service provider, until the electronic card receives its key exchange response. 

41. A method of conducting an electronic transaction among multiple parties arranged in a 
hierarchical organization comprising the steps of: 
30 sending a transaction request message from an electronic card to a first party where the first 

party is a message router or participant; 

sending the transaction request message to a next party X jk (j = 2, 3, 4, . . . ; k = 1 , 2, 3, . . .m; 
m is a variable of type n; n= 1 , 2, 3 , . . . ; m can be different values for different values of j) if the 
first party is a message router; 
35 combining a first party's transaction request message with the electronic card's transaction 

request message and sending the combined transaction request message to a next party X jk if the 
first party is a participant; 

sending the transaction request message to the next party X j>k if a current party X jjk is a 
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1 message router; 

combining a current party X j k 's transaction request message with the last party's transaction 

request message and sending the combined transaction request message to the next party X Jk , if 

the current party X jk is a participant; 
5 formatting, by the service provider, into one message, a transaction response for each 

participant and sending the message in reverse order of the path for sending the transaction 

request message to the service provider; and 

separating, by every participant, the transaction response for itself from the transaction 

responses for the other participants, and forwarding the remaining transaction responses to the 
10 other participants in reverse order of the path for sending the transaction request message to the 

service provider, until the electronic card receives its transaction response. 
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•nD SP . M *PLAINTEXT SP .M»E M . PK (RN S p. M *RNM*Skey M *STD S p.M) 



FROM STEP 204 FIG. 6E 




216 



SERVICE PROVIDER COMBINES: [TID SP . EC *PLAIN TEXT SP EC 

*E E c.PK*(RN S p. EC *RN E c*Skey E c*STD SP . EC )]*DSsp.p rlvate . K ey 
*[TID S p. M *PLAIN TEXT S p.M*EM.p K (RNsp.M*RNM*Skey M *STD S p. M )] 



I 



222 



SP HASHES AND PRODUCES A MESSAGE DIGEST : 

H{[TID S p. EC *PLAINTEXT SP . EC *E E c. PK (RN SP . E c*RN EC *Skey E c*STD E c)] 
*DS SP 

-Private-Key 

♦[TID SP . M *PLAIN TEXT S p. M 
*E M -PK(RNsp.M*RNM*Skey M *STD S p. M )]}=MD S p. M 



READ SP 
Private Key 



I 



224 



228 



USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR: E S p.p rivate . Key (MD S p. M )=DS SP 

-Private-Key 
( -226 



SERVICE PROVIDER COMBINES: 

«{[TID S p. E c*PLAINTEXTs P . E c*(E E c. PK *RN S p. EC *RN EC *Skey EC *STD S p. E c)] 
♦DS SP . Privil , e . Key } *[TID SP . M *PLAIN TEXT S p. M 
*E M .p K (RNs P .M*RN M *Skey M *STD SP . M )]»DS SP . P riv« e . Key 
=[(TID S p. EC *PLAINTEXT S p.p rivilte . Key *CRYPTOsp. E c)*DS S p.p fiv , te . Key 
*(TID S p.M*PLAIN TE XT S p, M *CRYPTO SP , M )]*DS SP .p riv . te . Key 

* 230 



7^ 



TO STEP 232 FIG. 6G 
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SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



FIG. 6G 



FROM STEP 230 FIG. 6F /V£Tiy#&K 




FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



Step 3 in FIG. 2 



(1) Merchant separates the DSsp. Private . Key . (2) Merchant hashes the data portion of 
the SP's KE response message: H[(TID SP . EC *PLAIN TEXT S p. EC *CRYPTO SP EC ) 
*DS S p.p rivate . Kcy *(TID S p. M *PLAINTEXT SP .M*CRYPTO S p. M )]=MD A M 

(3) Merchant separates the data portion of the SP's KE response message- 

TID SP . M , PLAIN TEXT SP . M , CRYPTO SP _ M , 
~. x [( TID sp-ec*PLAIN TEXTsp.Hc^RYPTOs^J^DSs,,.^.^ 

(4) Merchant verifies: D SP . Public . Key (DS S p.p ri v.,c.Kc y )=MD M (Refer to FIG. 5) 




_ MERCHANT DECIPHIER: D Merchan ,. Privale . Key (CRYPTO S p. M ) 

- D Merchant-Priv«te-Key rEMerchanl.Public.Key(RNsp- M *RN M *Skey M *STD SP . M )] 

Recover RN M , Is RN M identical with RN M in step i48 FIG. 6B? If yes, then 
(1) Merchant forwards SP's KE response message to EC: 
(TID SP . EC *PLAIN TEXT SP . EC *CRYPTO S p. EC * DS S p.p rivMe . key ) to step 260 FIG. 6H 
(2) Merchant prepares transaction phase of the transaction to step 244 FIG. 6 H 




START OF MERCHANT'S 
TRANSA CTION PHASE 



TO STEP 260 FIG. 6H 



TO STEP 244 FIG. 6H 
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246 



FIG. 6H 

FROMSTEP240 FIG. 6G 



Random Number SP (see 208) sent 
to Merchant (see 238): RN SP . M 



Merchant's sensitive transaction 
data to SP: STD M 



250 



I 



f 248 



MERCHANT'S ACCOUNT 
INFORMATION: AI M 



TARNSACTION 
AMOUNT: TA 



I 



252 



MERCHANT'S ENCIPHIRS: USE SP'S SESSION KEY FOR MERCHANT- 
Skey M (RN SP . M *STD M *AI M *TA)=CRYPTO M 



244 



Transaction Identification Number SP (see 218) 
assigned to merchant (see 232): TID S p. M 
-256 j 



Merchant's plain Text 
to SP: PL AIN TEXTj^ 



MERCHANT COMBINES: 
TIDspVTLAIN TEXT M *CRYPTO M 



258 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



254 



TO STEP296 FIG. 6 J 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



FROM STEP240 FIG. 6G 



Step 4 in FIG. 2 



(1) EC separates the DS SP .p rivate . Key , and hashes the data portion of the message- 

H(TID SP . EC *PLAIN TEXT SP . EC *CRYPTO S p. EC )=MD* S p Ec 

(2) EC separates: TID SP . EC , PLAIN TEXT SP . EC , CRYPTO SP . EC , DS S p. Private . key 
(5) EC venfies: P S p.p U bii C .K ey (DSsp.p r i va , e . Key )=MD SP . EC (Refer to FIG.5) 



264 



260 



REJECTED 



NO 



Is MD A SP . EC equal to MD^.^ 



262 



TO STEP266 FIG. 61 



YES 
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y 266 



FIG. 61 

FROMSTEP262 FIG. 6H 
i 



EC'S DECIPHIER: D EC . Privatc . Kcy (CRYPTO S p. EC )=D EC . Privatc . K ^ y 
[ E ECPubiic-Key(RNsp-EC* RN EC* ske yEC* STD SP-Ec)3; And recovers RN EC 




270 



REJECTED 



274 



YES 



RANDOM NUMBER SP (see 184) 
SENT TO EC (see 266): RN SP . EC 



SENSITIVE TRANSACTION 
DATA EC TO SP: STD EC 



278 



J 



TART OF EC'S TRANSACTION PHASE 



EC'S ACCOUNT INFORMATION:AI EC 



276 



TRANSACTION 
AMOUNT: TA 



280 



EC'S ENCIPHIR: USE SP'S SESSION KEY FOR EC: 
Skey EC (RN SP . EC *STD EC *AI EC *TA)=CRYPTO EC 



272 



Transaction Identification Number SP (see 194) 
assigned to EC (see 260): TID SP . Fr; 



284 



EC's PLAIN TEXT: 
PLAIN TEXT Fr 



286 



EC COMBINES : TID EC * PLAIN TEXT EC *CRYPTO EC 



282 



EC HASHES AND PRODUCES A MESSAGE DIGEST: 
H[TID SP . EC *PLAINTEXT EC *CRYPTO EC ]=MD EC 


t 288 






r 


READ EC'S 
Private Key 


-> 


USE EC'S DIGITAL SIGNATURE GENERATOR: 

EEC-Private-Key(MD EC )=DS EC _ Private _ Key 



292 



290 



tz: 



EC COMBINES: [TID SP . EC * PLAIN TEXT EC 
*Skey E c(RN S p. EC *STD EC *AI EC *TA)]*DS E c 

-Private-Key 



294 



•Step 5 in FIG. 2 



TO STEP296 FIG. 6 J 

SUBSTITUTE SHEET (RULE 26) 



WO 99/57835 



PCT/US99/09938 



15/29 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



FIG. 6 J 



NETWORK 



FROM STEP294 FIG. 61 




FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



FROM STEP254 FIG. 6H 



MERCHANT COMBINES: 

[TID S p. E c*PLAINTEXT EC *Skey EC (RN S p. EC *STD E c*AI E c*TA)]*DS E c.privMc- K cy 
*[TIDsp.M*PLAINTEXT M *Skey M (RN S p. M *STD M *AI M *TA)] 
=(TID SP . EC *PLAIN TEXT EC *CRYPTO EC )*DS EC .p rivate . K c y 
*(TID SP . M *PLAIN TEXT M * CRYPTO m ) 



TZ 



296 



MERCHANT HASHES AND PRODUCES A MESSAGE DIGEST- 

H[(TID S p. EC *PLAIN TEXT EC *CRYPTO E cp)*DS EC .p ri v, te -K« 
*(TID S p. M *PLAIN TEXT M * CRYPTO m )]=MD m 



MERCHANT'S 
Private Key 

tz 



TZ 



298 



302 



USE MERCHANT'S DIGITAL SIGNATURE 
GENERATOR: E M .p fivale . Key (MD M )=DS M . P nv« te .Kc y 

_ZZ_ Z- 300 



MERCHANT COMBINES: 
{[TID S p. E c*PLAINTEXT EC *Skey E c(RN SP . E c*STD EC *AI E c*TA)]*DS EC .p rivate . Key 
*[TID SP . M *PLAIN TEXT M *Skey M (RN SP . M *STD M *AI M *TA)]} *DS M -p ri va«c-K e v 
=[(TID SP . E c*PLAINTEXT E c*CRYPTO EC )*DS EC .p rivate . Key 
*(TID sp .m*PLAIN TEXT M * CRYPTO M )]*DSM- Pri v. te - K cy 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



TZ 



304 



Step 6 in FIG. 2 



r NETWORK 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



1 



306 



(I) SP checks TID SP . M and TID SP . EC to make sure they are valid (see 218 and 194), 
if one of them is invalid then rejected 308. (2;SP separates DS M . Priv>te . Key . 

(3) SP hashes the data portion of the transaction request message obtains MD A M . 

(4) SP separates the data portion of the transaction request message and obtains* 

TID S p. M , PLAIN TEXTm, CRYPTO M> DS M . Privatc . Key , 
(TIDsp.Ec*PLAINTEXT E c*CRYPTO E c)*DS EC .p fivate .Kcy 



308 



REJECT 



TIDsp-m or TID SP . EC is invalid 



T 



TO STEP 310 FIG. 6K 
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FIG. 6K 

FROMSTEP306 FIG. 6 J^j^ 



310 



Use PK M to verify the DS M . Privatc . K Is MD A M =MD M 7 (Refer to FIG. 5) 
314 ±_ ^312 



X 



REJECT 



NO 




316 



Skey M decrypts CRYPTO M , recovers RN SP . M , RN SP . M =RN SP . M in 208 FIG. 6E? 
r 320 NO J / 318 



REJECT 



^Nscji£2^ect? V erify AI M andJA,. 
I YES 



322 



(I) SP separates DS EC _ Privatc _ Key , hashes the data portion of EC's transaction request 
message: H(TID SP . EC *PLAIN TEXT EC *CRYPTO EC )=MD A EC 
(2) SP separates and obtains:TID SP . EC , PLAIN TEXT EC , CRYPTO EC , DS EC Private 



Key 



I 



>324 



SP uses PK EC to verify DS EC . Private . Kev , Is MD A EC =MD Kr ? (Refer to FIG. 5) 



X 



328 



REJECT 



NO 




>330 



Skey M decrypt CRYPTO EC> recovers RN SP . RC , RN SP . EC =RN SP . EC in 184 FIG. 6D? 




END OF KE PHASE 



X 



338 



SP's Response Data SP . EC to EC 



YES 

-► TO STEP 354 
FIG. 6L 



> 336 



SP USES Skey EC TO ENCRYPT: E Skev . Rr (Response Data SP . Rr )=CRYPTO 



Transaction Identification Number SP 
(see 194) assigned to EC: TID SP . EC 



342 



SP-EC 



SP'S PLAIN TEXT TO EC: 
PLAIN TEXT SP . EC 

| (— 344 ~ 



SERVICE PROVIDER COMBINES: TID SP . EC *PLAIN TEXT, 



1 SP-EC 



^Skey- EcCResponse Data SP . EC )=TID SP . EC *PLAIN TEXT SP . EC *CRYPTO SP . E C 

^ TO STEP 346 and 352 FIG. 6L 
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FIG. 6L 

FROM STEP 340 FIG. 6K- 

i 



SERVICE PROVIDER HASHES AND PRODUCES A MESSAGE DIGEST 
H[TID SP . EC *PLAIN TEXT S p. E c*E skey . EC (Response Data S p. EC )]=MD S p .Ec 



READ SP'S 
Private Key 



346 



USE SERVICE PROVIDER'S DIGITAL SIGNATURE 

GENERATOR : Esp.Priv«tc -Key(MP S p.Ec) = DSsp .Privrtc.Kcy 

~0- 348 



^- 350 I C- 3 4{ 

SERVICE PROVIDER COMBINES : 
[TID S p. E c*PLAIN TEXT S p. E c*Eskey.Ec(Response Data S p. EC )]*DS S p.p rivate . Key 
= (TID SP . EC *PLAIN TEXT S p, EC *CRYPTO S p. E c)*DS S p.p rivate . Key 

FROM STEP 332 FIG. 6K 352 



SP's Response Data SP . M to MERCHANT 



TZ 



356 



SP USES Skey M TO ENCRYPT: E Sk , y . M (Response Data SP . M )=CRYPTO S p. M 



Transaction Identification Number SP (see 
218) assigned to Merchant (see 232): TID S p. M 



it (see 231 
£—360 



TZ 



354 



SP's plain text to merchant: 
PLAIN TEXTsp-m 



CZ 



362 



SERVICE PROVIDER COMBINES: TID S p. M *PLAIN TEXT S p. M 
*E skey . M (Response Data S p. M )=TID S p. M *PLAIN TEXT SP . M *CRYPTO S p. M 



TZ 



358 



SERVICE PROVIDER COMBINES: 
[(TID S p. EC *PLAINTEXT S p. EC *E Skey . EC (Response Data S p.E C )]*DSsp.p riV a, e . Key 
*[TID sp .m*PLAIN TEXT S p.M*E Skey . M (Response Data SP . M )] 
=[(TID S p. E c*PLAINTEXTsp.EC*CRYPTO S p. E c)*DS S p.p rivate . Key 
*(TID SP . M *PLAINTEXT S p. M *CRYPTO SP . M )] 



366 



TZ 



364 



SERVICE PROVIDER HASHES AND PRODUCES A MESSAGE DIGEST 

H[(TID S p. EC *PLAINTEXT S p. EC *CRYPTO S p. EC )*DS S p.p rivate . Key 
*rnD5 8 P.M*PLAINTEXT S p.M*CRYPTO S p.M)^MP CT . > 



TO STEP 368 FIG. 6M <- 



TO STEP 372 FIG. 6M 
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FIG. 6M 



FROM STEP 364 FIG. 6L 



READ SP'S 
Private Key 



TZT 3 



FROM STEP 366 FIG. 6L 

i 



USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR : E SP , Pri vatc . Kcy (MD SP , M )=DS SP 

-Private-Key 



70 



368 



SERVICE PROVIDER COMBINES: 
<<{[TID SP . EC *PLAIN TEXT sp .ec*E^ 
♦[TID SP . M *PLAIN TEXT S p. M *E Skcy . M (Response Data SP _ M )]» DS^.^^ 
=[(TID SP . EC *PLAINTEXT SP . Privatc . Kcy *CRYPTO SP . EC )*DS SP . Privatc . Key 
*(TID SP . M *PLAIN TEXT SP . M *CRYPTO SP , M )]*DS s ^ y ^ y 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



372 



Step 7 in FIG. 2 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



(l) Merchant checks TID SP . M to make sure it is valid (218 and 232), if not rejected 368. 
(2) Merchant separates DS SP _ Privatc _ Kcy . (3) Merchant hashes the data portion of the 
message obtains MD A M . (4) Merchant separates the data portion of the message: 
TID SP . M , PLAIN T sp .m, CRYPTO SP . M , DS SP . Privatc . Kcy 
Prepare to forward (TID SP . EC *PLAIN TEXT SP .EC*CRYPTO SP . EC *DS SP _ Private _ Kcy ) 



REJECTED 



TID SP . M is invalid 



376 



374 



(1) Merchant use SP's session key for merchant received and decrypted 238 FIG. 6G: 
D S key-M(CRYPTO SP _ M )=D Skcy . M [E skcy . M (Response Data SP . M )] 
(3) Merchant use SPp^^.,^ to verify DSsp_ Pr j vatc _ Kc y (Refer to FIG. 5) 
D SP-p U b]ic-Key( D S S p-private-Key ) = MD SP . M , When MD SP . M equal to MD A SP . M then, 
send (TID SP . EC *PLAIN TEXT S p.E C *CRYPTO SP . EC *DS SP . Pfivate . key ) to 394 FIG 6N 



378 



TO STEP 380 FIG. 6N 



SUBSTITUTE SHEET (RULE 26) 



WO 99/57835 



PCT/US99/09938 



19/29 



FIG. 6N 



FROM STEP 370 FIG. 6M 




REJECTED 
( — -382 



Merchant's 
acknowledgement data to SP 
Acknowledgement Data M 



( — -386 



Forward SP 's message for EC 

^ 



MERCHANT'S ENCIPHIR: USE SP'S SESSION KEY FOR MERCHANT: 
Skey M (RN SP . M *AcknowledgementData M )=CRYPTO M 



384 



Transaction Identification Number assigned by 
SP (see 210 ) to Merchant (see 224 ): TID SP _ M 



390 



Merchant's Plain Text to 
SP: PLAIN TEXT M 



392 



MERCHANT COMBINES: TID SP . M *PLAIN TEXT M *CRYPTO M 



388 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



— * TO STEP 422 FIG, 6P 

Merchant forwards SP's message 
for EC; Step 8 in FIG. 2 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGrNATOR) 




(1) EC checks TID SP . EC to make sure it is valid (194, 260). If not valid rejected 396. 
(2) EC separates DS S p. Pr i V aie-Key (V EC hashes the data portion of the message 
obtains MD a sp-ec- (4) EC separates the data portion of the message: 
TIDsp.Ec, PLAIN TEXT SP . ECj CRYPTO SP . EC , DS SP 

-Private-Key 



REJECT 



TID SP . EC is invalid 
- 396 



394 



TO STEP 398 FIG. 60 
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FIG. 60 

\—l^FROM394 FIG. 6N 



(1) EC uses SP's session key for EC that received and decrypted in step 
266 FIG. 61: D Skcy . E c(CRYPTOsp.Ec )=D Skcy . M [E Skcy . EC (Response Data SP . EC )] 
(2) EC use Dsp.Pubiic.Kcy to verify DSsp. pr jvatc-Key (Refer to FIG, 5) 

PsP-Public-Kcy(PSsP-private-Kcy ) = MD S p. E c, Is MD S p. E c equal to MD A SP „ EC ? 









1 398 




NO 

< — 




r y 400 


REJECT 


Is MD A SP . EC equal to MDgp.pr? mrr=— 


/-406 




YES 




EC's acknowledgement data to SP 
Acknowledgement Data Pr 




r 404 


r 




r 



EC'S ENCIPHIR: USE SP'S SESSION KEY FOR EC: 
Skey EC (Acknowledgement Data EC )=CRYPTO EC 



Transaction Identification Number assigned 
by SP (see 186) to EC (see 252) :TID SP . EC 



tz: 



410 



EC'S PLAIN TEXT TO 
SP: PLAIN TEXT EC 



412 



EC COMBINES: TID SP _ EC *PLAIN TEXT EC *CRYPTO EC 



408 



EC HASHES AND PRODUCES A MESSAGE DIGEST: 
H[TID S p_ EC *PLAIN TEXT EC *CRYPTO E c]=MD EC 



READ EC'S 
Private Key 



414 



USE EC'S DIGITAL SIGNATURE GENERATOR: 

E£C-Privatc-Kcy(MDEc) = PS EC . Private . Key 



418 



416 



EC COMBINES: 

[TID S p-Ec*PLAINTEXT E c*Skey EC (Acknowledgement Data EC )]*DS E(> p rivate . Key 



TO STEP 422 FIG, 6P 



TZ 



-Step 9 in FIG. 2 



420 



SUBSTITUTE SHEET (RULE 26) 



WO 99/57835 



PCT/US99/09938 



21/29 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



NETWORK? 



FIG. 6P 

FROM STEP 420 FIG. 60 



FROM STEP 388 FIG. 6N 

i 



MERCHANT COMBINES : 
{[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data E c)]*DS EC .priv*e Key} 
*[TIDsp.M*PLArN TEXT M *Skey M (Acknowledgement Dataw)] 



422 



MERCHANT HASHES AND PRODUCES A MESSAGE DIGEST: 
H«{[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] 

♦DSEc-Private-Key} *[TID S p. M *PLAIN TEXT M 

* Skey M ( Acknowledgement Data M )]»=MD M 









J, ( 424 




READ MERCHANT'S 
Private Key 


— ► 


USE MERCHANT'S DIGITAL 
SIGNATURE GENERATOR: 

E M-Privatc-Kev ( MD M) =DS M-Priv<ite-Kev 




( 428 






r < 426 





MERCHANT COMBINES: 
«{[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] 
*DS EC -p r iv.,e-Kcy} * [TID SP . M *PL AIN TEXTm 
*Skey M (Acknowledgement Data M )]»*DS M . Pr , vate . Key 

= {[(TID SP . EC *PLAINTEXT EC *CRYPTO E c)*DS E c- PrI v«e.Key] 
*(TID S p. M *PLAIN TEXT M *CRYPTO M )} *DS M . Private . Key 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



430 



-Step 10 in FIG. 2 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



TO STEP 432 FIG. 6Q 
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FIG. 6Q 

FROM STEP 430 FIG. 6P 

i 



432 



(1) SP checks TID SP . M ^ TID SP . EC to make sure it is valid (see 218 and 194 ), 
if one of them is not valid then rejected 434. (2) SP separates DSM.privatc.Kcy. 

(3) SP hashes the data portion of the message obtains MD A M . 
(4) SP separates the data portion of the message: TID SP . M , PLAIN TEXT M » 

CRYPTOm, PS M .Private.Ke y > (TID SP . EC » PLAIN TEXTgc * CR YPTOec) * PSec-Privatc-Kcy 




ither TID SP . M 
or TID SP . EC is invalid 



T436 



SP uses PK M (see 150 and 1 70) to verify the decrypt DS^p^^.,^ (Refer to FIG. 5). 

)=MD M , Is MD M =MD A M ? 



440 



REJECT 



NO 




442 



SP uses Skey M (see 210) to decrypt CRYPTO^ and obtains Acknowledgment Data M 




r 444 


(1) SP separates DS E c-p r iv«te-Key> (2) hashes the data portion of EC's acknowledgement 

message: H(TID SP . EC *PLAIN TEXT EC *CRYPTO EC )=MD A EC 
(3) SP separates and obtains: TID SP -eo PLAIN TEXT EC , CRYPTO EC , DS EC -Priv«e-K e y 




r 446 


SP uses PK EC (see 126 and 176) to decrypt DS EC . Prjvate . Key (Refer to FIG. 5). 

D EC-Public-Key( DS EC-Private-Key ) =MD EO Is MD EC =MD A EC ? 


NO 3 




REJECT < =^m_MD2£c= 






r YES y 452 



SP uses Skey EC (see 1 86) to decrypt CRYPTO EC and obtains Acknowledgment Data EC 


END OF TRANSACTION PHASE 






TRANSACTION COMPLETED 
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FIG. 13 
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